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，把关键信息存进去，后续由外部程序轮询或告警。
- 表结构要精简：至少包含
trigger_name、table_name、operation_type（INSERT/UPDATE/DELETE）、error_msg、created_at - 避免在触发器里拼接长文本或调用复杂函数，防止二次报错；
error_msg字段建议用TEXT，别设太小 - 确保该表引擎为
InnoDB，且触发器用户有INSERT权限——权限不足会导致静默失败 - 不要在触发器里对这张日志表做
SELECT ... FOR UPDATE或其他事务敏感操作，它只是“单向记录”
在触发器里主动捕获并写日志
MySQL 触发器无法“捕获”异常，但可以“预防+兜底+记录”。重点不是等崩了再救，而是提前检查、显式抛错、顺便落日志。
- 用
IF判断常见风险点：比如NEW.price IS NULL AND price NOT NULL，或NEW.status NOT IN ('pending','done') - 检查后直接
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'xxx'，这样应用层能拿到明确错误，也方便你后期从日志表里筛选同类问题 - 如果逻辑较重（比如要查关联表），务必加
ROW_COUNT() = 0判断，避免SELECT ... INTO查不到时静默设为NULL导致后续字段违规 - 写日志语句放在触发器开头或判断分支末尾，别嵌套在深层
IF ... ELSE里——容易漏执行
注意事务回滚会连带删掉日志行
触发器和主 DML 共享同一事务。如果主语句因约束冲突回滚，你刚插进 trigger_failure_log 的那条记录也会被撤销——日志就没了。解决办法只有一个：把日志表引擎换成 MyISAM 或用 INSERT DELAYED（已弃用），都不现实；真正可行的是改用 AFTER 触发器 + 显式 COMMIT 分离事务，但这违反 MySQL 触发器设计原则，极易出错。 所以实际做法是：接受这个限制，在日志表上加监控，定期比对业务表变更与日志表记录数是否匹配，发现缺失再查 binlog 补溯。
