mysql触发器中的异常与错误管理

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 在触发器里基本无用

替代方案：把校验和修复逻辑移到应用层或存储过程中

真正健壮的错误管理，得绕开触发器本身的能力限制。例如：

• 需要根据另一张表状态决定是否允许插入？别在 BEFORE INSERT 里查表后 SIGNAL，而应在应用代码里先 SELECT 判断，再决定是否发 INSERT
• 想自动补全缺失字段（如生成 created_at 或格式化手机号）？可以用 BEFORE INSERT/UPDATE 直接赋值，但前提是字段允许 NULL 或有默认值，且逻辑简单无副作用
• 涉及多表一致性、复杂条件分支、日志记录或重试机制？封装成存储过程，由应用显式调用，而不是塞进触发器

触发器适合做轻量、确定性、无外部依赖的操作，比如更新统计字段、复制时间戳、小写化邮箱。一旦出现 SELECT …… FROM other_table 或嵌套 IF 判断多个业务规则，它就不再是“辅助工具”，而成了故障放大器。

调试触发器错误时，SHOW ENGINE INNODB STATUS 和错误日志最管用

触发器报错往往不直接显示具体哪行代码崩了，尤其是嵌套调用或与外键冲突交织时。这时候：

• 执行失败后立刻运行 SHOW ENGINE INNODB STATUSG，查看 LATEST FOREIGN KEY ERROR 或 LATEST DETECTED DEADLOCK 区块
• 检查 MySQL 错误日志（路径由 log_error 配置项指定），搜索最近的 Error 或 ERROR 行，常含触发器名和 SQLSTATE
• 临时把触发器改成只写日志（如插入到一张 debug_log 表），确认执行路径是否如预期——但注意：写日志操作本身也可能触发新错误

没有堆栈跟踪，没有行号提示，是 MySQL 触发器调试最让人头疼的一点。写得越“聪明”的触发器，出问题时越难定位。