会回滚，且整个事务从隐式起点开始全部撤销；触发器报错常静默失败，需用show warnings、show engine innodb status或signal主动抛错定位真实原因。
触发器报错时DML事务会静默回滚，根本看不到错误信息
MySQL 5.7默认把触发器内的SQL异常当作整个语句失败处理，但INSERT/UPDATE/DELETE语句本身只返回通用错误码（如ERROR 1054 (42S22)），不会透出触发器里哪一行、哪个函数出的问题。这是最常被忽略的排查盲区——你以为是主表字段写错了，其实是在BEFORE INSERT触发器里调用了不存在的my_udf()。
用SHOW ENGINE INNODB STATUS抓取最近的死锁与事务异常快照
该命令输出中LATEST DETECTED DEADLOCK段虽然名字叫“死锁”，但MySQL 5.7实际也会把触发器内未捕获的错误（如除零、空指针引用、子查询返回多行）记录在TRANSACTIONS部分的“latest SQL”字段里。重点看：
- 是否有
Trx has been rolled back紧挨着trigger或function字样 -
mysql tables in use是否列出触发器关联的表（哪怕你只操作了主表） - 时间戳是否与你执行DML的时间吻合
注意：该状态每15秒刷新一次，且只保留最后一次异常，执行后要立刻查。
临时禁用触发器并手动模拟执行逻辑
MySQL 5.7不支持DISABLE TRIGGER语法，只能靠注释或重命名绕过：
- 用
RENAME TABLE把触发器对应表改名（如RENAME TABLE orders TO orders_off），再建同名视图或空表占位，让触发器失效 - 把触发器定义里的SQL体单独复制出来，替换
NEW.xxx为具体值，用SELECT或SET @var := ...方式逐行执行 - 特别检查
SELECT ... INTO语句——若子查询返回0行或>1行，会直接报ERROR 1326 (HY000)或ERROR 1172 (42000)
在触发器里加SIGNAL主动抛出可识别的错误码和消息
MySQL 5.7支持SIGNAL SQLSTATE '45000'，比依赖隐式异常更可控：
BEGIN
DECLARE v_count INT DEFAULT 0;
SELECT COUNT(*) INTO v_count FROM config WHERE key = 'tax_rate';
IF v_count = 0 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Missing tax_rate in config table';
END IF;
END
这样DML失败时客户端能明确看到ERROR 1644 (45000): Missing tax_rate in config table，而不是笼统的ERROR 1064。但要注意：SIGNAL不能在存储函数里用，只适用于触发器和存储过程。
真正卡住人的往往不是语法，而是触发器嵌套调用另一个存储过程，而那个过程又调用了外部UDF——这种链路一旦出错，错误堆栈全被MySQL吞掉。务必在每个可能出错的节点加SIGNAL或日志表写入，别信“它应该能自己报错”。
