MySQL触发器不支持TRY...CATCH，错误会直接中断语句并回滚；仅能用SIGNAL抛出自定义错误，RESIGNAL在触发器中无效；复杂逻辑应移至应用层或存储过程。
MySQL 触发器里不能用 TRY...CATCH
MySQL 原生不支持 TRY...CATCH 语法，这是很多从 SQL Server 或 PostgreSQL 转过来的人第一脚踩空的地方。触发器中一旦执行出错（比如插入违反唯一约束、除零、NULL 写入 NOT NULL 字段），整个语句会立即中断并回滚，且无法在触发器内部“捕获”并转为警告或默认值。
这意味着：你不能靠触发器兜底业务逻辑错误。常见误操作包括在 BEFORE INSERT 里做复杂校验后想“悄悄修正字段”，结果一报错就整个 INSERT 失败——不是触发器没运行，而是它运行到一半被 MySQL 强制终止了。
SIGNAL 和 RESIGNAL 是唯一可控的报错方式
MySQL 5.5+ 提供了 SIGNAL 语句，允许你在触发器中主动抛出自定义错误，配合 SQLSTATE 码和消息，让调用方明确知道问题在哪。它不会被“吞掉”，而是像原生错误一样中断执行、回滚事务。
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '用户名已存在且邮箱未验证';-
SQLSTATE '45000'是用户自定义错误的标准码；用'45001'、'45002'也能区分不同场景 - 必须在
BEGIN...END块内使用，且不能放在函数或存储过程调用之后（否则可能被忽略） -
RESIGNAL只能在异常处理器（DECLARE ... HANDLER）中使用，但注意：触发器不支持声明异常处理器——所以RESIGNAL在触发器里基本无用
替代方案：把校验和修复逻辑移到应用层或存储过程中
真正健壮的错误管理，得绕开触发器本身的能力限制。例如：
本书将PHP开发与MySQL应用相结合，分别对PHP和MySQL做了深入浅出的分析，不仅介绍PHP和MySQL的一般概念，而且对PHP和MySQL的Web应用做了较全面的阐述，并包括几个经典且实用的例子。 本书是第4版，经过了全面的更新、重写和扩展，包括PHP5.3最新改进的特性（例如，更好的错误和异常处理），MySQL的存储过程和存储引擎，Ajax技术与Web2.0以及Web应用需要注意的安全
- 需要根据另一张表状态决定是否允许插入？别在
BEFORE INSERT里查表后SIGNAL，而应在应用代码里先SELECT判断，再决定是否发INSERT - 想自动补全缺失字段（如生成
created_at或格式化手机号）？可以用BEFORE INSERT/UPDATE直接赋值，但前提是字段允许NULL或有默认值，且逻辑简单无副作用 - 涉及多表一致性、复杂条件分支、日志记录或重试机制？封装成存储过程，由应用显式调用，而不是塞进触发器
触发器适合做轻量、确定性、无外部依赖的操作，比如更新统计字段、复制时间戳、小写化邮箱。一旦出现 SELECT ... FROM other_table 或嵌套 IF 判断多个业务规则，它就不再是“辅助工具”，而成了故障放大器。
调试触发器错误时，SHOW ENGINE INNODB STATUS 和错误日志最管用
触发器报错往往不直接显示具体哪行代码崩了，尤其是嵌套调用或与外键冲突交织时。这时候：
- 执行失败后立刻运行
SHOW ENGINE INNODB STATUS\G，查看LATEST FOREIGN KEY ERROR或LATEST DETECTED DEADLOCK区块 - 检查 MySQL 错误日志（路径由
log_error配置项指定），搜索最近的Error或ERROR行，常含触发器名和 SQLSTATE - 临时把触发器改成只写日志（如插入到一张
debug_log表），确认执行路径是否如预期——但注意：写日志操作本身也可能触发新错误
没有堆栈跟踪，没有行号提示，是 MySQL 触发器调试最让人头疼的一点。写得越“聪明”的触发器，出问题时越难定位。
