mysql触发器不支持异常捕获，因设计上禁用declare handler和try...catch；错误发生即中止语句并回滚事务，仅能通过signal主动抛出异常，无法捕获或恢复。
MySQL触发器根本没机会执行异常捕获逻辑
因为 MySQL 触发器不支持 DECLARE HANDLER，也没有 TRY...CATCH 语法——这不是功能“没写好”，而是设计上就禁止在触发器上下文中做错误恢复。一旦触发器内部执行出错（比如 INSERT 违反唯一约束、NEW.invalid_col 引用不存在字段、对同一张表做修改），MySQL 会立即中止整个语句，并回滚事务，连 BEGIN...END 块里后续的任何语句都不会运行，更别说捕获了。
你看到的“错误”其实根本没进触发器
常见误判是以为触发器“运行失败了但没报错”，实际是：错误发生在触发器执行前或执行中途，MySQL 直接跳过剩余逻辑并向上抛出。例如：
-
ERROR 1442 (HY000)：在触发器里更新被触发的表 → 错误由 MySQL 内核拦截，触发器甚至没开始执行 -
ERROR 1062 (23000)：主键冲突 → 约束检查发生在引擎层，触发器逻辑已结束，无法干预 -
ERROR 1327 (42000)：引用NEW.nonexistent_col→ 解析阶段就失败，不会进入运行时
唯一可控的“异常”只能靠 SIGNAL 主动抛出
你只能在明确知道某条件不满足时，提前用 SIGNAL 中断流程，但这不是“捕获异常”，而是“主动制造异常”。例如：
BEGIN
IF NEW.status NOT IN ('draft', 'active') THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid status value';
END IF;
END
注意：
-
SIGNAL必须在BEGIN...END块内，且不能放在函数调用之后（否则可能被忽略） -
RESIGNAL在触发器中无效，因为它只在DECLARE HANDLER块里才有意义，而触发器不支持该声明 - 这种“报错”仍会导致主语句失败和事务回滚，无法实现“记录日志后继续执行”
真正要记录错误上下文，得绕开触发器本身
想留痕？别指望触发器自己写日志。它连出错时的 ERROR_NUMBER() 都拿不到——因为那些函数只在存储过程的 CATCH 块里有效。可行路径只有：
- 把校验逻辑提到应用层或存储过程中，在那里用
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION捕获并记日志 - 用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO替代可能冲突的插入，避免触发约束错误 - 调试时用
SHOW WARNINGS查最近错误，或开log_error_verbosity = 3看错误日志，而不是在触发器里加SELECT输出
触发器的边界很硬：它只适合做确定性、无副作用、不依赖外部状态的轻量操作。一旦涉及错误分支、多表联动或日志落盘，就已经超出了它的能力范围。
