如何记录MySQL触发器执行异常

MySQL触发器无法捕获异常，唯一可靠记录异常的方式是在触发器中主动写入专用错误日志表trigger_failure_log，并配合SIGNAL或显式判断拦截问题；error_log不记录触发器错误，general_log无法区分执行成败且无错误上下文。

MySQL触发器本身不支持 TRY...CATCH，也没法直接写错误日志到文件或发告警，记录异常的唯一可靠方式是：在触发器里主动写入一张独立的错误日志表，并配合 SIGNAL 或显式判断提前拦截问题。

为什么不能依赖 error log 或 general_log

MySQL 的 error log（由 log_error 配置）只记录服务级错误，比如崩溃、权限拒绝、表损坏，不记录触发器执行失败。即使触发器因 ERROR 1442 或 ERROR 1048 中断，也不会出现在 error.log 里。general_log 虽然会记下触发器被调用的原始语句，但它不区分成功/失败，也不包含错误码或上下文，查起来像大海捞针。

建一张专用的 trigger_failure_log 表

这是最轻量、最可控的方案。触发器只需一条 INSERT INTO，把关键信息存进去，后续由外部程序轮询或告警。

1. 表结构要精简：至少包含 trigger_name、table_name、operation_type（INSERT/UPDATE/DELETE）、error_msg、created_at
2. 避免在触发器里拼接长文本或调用复杂函数，防止二次报错；error_msg 字段建议用 TEXT，别设太小
3. 确保该表引擎为 InnoDB，且触发器用户有 INSERT 权限——权限不足会导致静默失败
4. 不要在触发器里对这张日志表做 SELECT ... FOR UPDATE 或其他事务敏感操作，它只是“单向记录”

在触发器里主动捕获并写日志

MySQL 触发器无法“捕获”异常，但可以“预防+兜底+记录”。重点不是等崩了再救，而是提前检查、显式抛错、顺便落日志。

1. 用 IF 判断常见风险点：比如 NEW.price IS NULL AND price NOT NULL，或 NEW.status NOT IN ('pending','done')
2. 检查后直接 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'xxx'，这样应用层能拿到明确错误，也方便你后期从日志表里筛选同类问题
3. 如果逻辑较重（比如要查关联表），务必加 ROW_COUNT() = 0 判断，避免 SELECT ... INTO 查不到时静默设为 NULL 导致后续字段违规
4. 写日志语句放在触发器开头或判断分支末尾，别嵌套在深层 IF ... ELSE 里——容易漏执行

注意事务回滚会连带删掉日志行

触发器和主 DML 共享同一事务。如果主语句因约束冲突回滚，你刚插进 trigger_failure_log 的那条记录也会被撤销——日志就没了。解决办法只有一个：把日志表引擎换成 MyISAM 或用 INSERT DELAYED（已弃用），都不现实；真正可行的是改用 AFTER 触发器 + 显式 COMMIT 分离事务，但这违反 MySQL 触发器设计原则，极易出错。 所以实际做法是：接受这个限制，在日志表上加监控，定期比对业务表变更与日志表记录数是否匹配，发现缺失再查 binlog 补溯。