MySQL触发器无法捕获运行时错误，出错即回滚终止；应将校验逻辑移至存储过程并用EXIT HANDLER记录错误，或由应用层捕获异常并落日志。
MySQL触发器里根本捕获不到运行时错误
MySQL 触发器（BEFORE 或 AFTER）本身不支持 DECLARE HANDLER，也不能用 TRY...CATCH——这和存储过程不同。一旦触发器里执行出错（比如插入非法数据、除零、外键冲突），整个语句直接回滚，触发器中断，你什么也捞不到。
常见错误现象：ERROR 1422: Explicit or implicit commit is not allowed in stored function or trigger，或者更隐蔽的：ERROR 1048: Column 'xxx' cannot be null，但日志里没留下任何痕迹。
- 触发器不是异常处理单元，它是“原子操作的一部分”，出错即终止
- 想记录报错，不能靠触发器自己 try/catch，得绕开它
- MySQL 5.7+ 支持
GET DIAGNOSTICS，但它在触发器中不可用
用存储过程封装业务逻辑再调用触发器
把原本直连表的 INSERT/UPDATE 操作，改成调用一个带错误处理的存储过程；触发器只做轻量级、高确定性的检查（比如生成 UUID、更新时间戳），不承担校验或计算逻辑。
示例场景：用户注册时要写 users 表，同时记录操作日志。别让触发器去校验邮箱格式或查重——这些该由存储过程做：
DELIMITER $$
CREATE PROCEDURE sp_insert_user(IN p_email VARCHAR(255))
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
INSERT INTO error_log (error_msg, created_at)
VALUES (CONCAT('Failed to insert user: ', MYSQL_ERRNO(), ' - ', MESSAGE_TEXT), NOW());
RESIGNAL;
END;
INSERT INTO users (email) VALUES (p_email);
END$$
DELIMITER ;
- 触发器只保留
BEFORE INSERT中的纯赋值逻辑（如NEW.created_at := NOW()） - 所有可能失败的校验、查询、计算，全挪到调用方（即这个存储过程）里
- 这样
RESIGNAL能把原始错误抛给客户端，同时已写入error_log
用外部应用层兜底记录错误
如果无法改造 SQL 调用路径（比如 ORM 直接 INSERT），那就放弃在数据库侧捕捉，改由应用代码捕获异常并落库。
关键点不是“怎么在 MySQL 里抓错”，而是“哪一层最适合记录上下文”——应用层知道完整请求参数、用户 ID、接口名，数据库只看到一行变更。
- PHP/Python/Java 等语言的 MySQL 驱动都能捕获
SQLSTATE和错误码（如23000表示约束冲突） - 记录时带上
errno、sqlstate、原始 SQL 片段（脱敏后）、执行耗时 - 避免在触发器里写
INSERT INTO log_table—— 它可能因锁表、磁盘满、权限不足而二次失败，导致主操作也失败
替代方案：用 MySQL 错误日志 + 审计插件定位问题
真要追溯触发器引发的错误，别指望它自己打日志。MySQL 的 error_log 会记录触发器内部报错（如语法错误、变量未声明），但不会记录业务逻辑错误（如 INSERT ... SELECT 返回空集）。
如果你用的是 MySQL 5.6+ 企业版或 Percona Server，可以启用 audit_log 插件，它能记录所有到达服务器的语句及返回状态，包括触发器执行失败的上下文。
- 配置项：
audit_log_policy = ALL，配合audit_log_format = JSON - 注意性能影响：审计日志是同步写磁盘的，高频写入会拖慢 QPS
- 开源版 MySQL 可用
general_log临时开启，但只记录语句不记录结果，排查效率低
真正难的不是“怎么记”，而是“记什么才有用”——触发器报错往往意味着业务逻辑和数据约束已经耦合过深，修复根因比补日志更重要。
