MySQL触发器报错会回滚整个主操作，非仅跳过触发器；可通过information_schema.TRIGGERS定位、ALTER TABLE DISABLE TRIGGER临时禁用；BEFORE触发器中NEW/OLD可用性有严格限制；调试宜用debug_log表或SELECT错误信息“漏出”变量值。
触发器里 INSERT 或 UPDATE 报错直接中断主操作
MySQL 触发器执行失败时，会回滚整个语句（包括原始的 INSERT），不是只跳过触发器。这是默认行为，很多人误以为触发器“出错就忽略”，结果发现数据根本插不进去。
- 错误通常表现为：
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails，或自定义的SIGNAL SQLSTATE '45000'引发的中断 - 触发器中任何未捕获的异常（比如除零、空值插入非空字段、违反外键）都会让主语句失败
- 没有
TRY...CATCH机制，MySQL 5.7+ 也不支持在触发器里用DECLARE ... HANDLER捕获所有错误（仅支持部分条件，且不能处理 SQLSTATE 45000）
怎么快速定位是哪个触发器在捣鬼
别先翻代码，先查激活中的触发器和执行顺序。多个触发器叠加时，错误堆栈不显示具体是哪一个。
- 运行
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'your_table_name';确认哪些触发器存在、类型（BEFORE INSERT还是AFTER INSERT）、定义体 -
BEFORE类型触发器出错会直接阻断插入；AFTER出错同样阻断（因为事务未提交） - 临时禁用某个触发器：MySQL 8.0+ 支持
ALTER TABLE your_table DISABLE TRIGGER trigger_name;；低版本只能删掉再重建（务必备份SHOW CREATE TRIGGER结果）
NEW 和 OLD 在不同触发时机下的可用性与陷阱
写触发器时最常踩的坑是误用 NEW 或 OLD，尤其在 BEFORE DELETE 里读 NEW.id，或者在 BEFORE INSERT 里给 OLD.col 赋值——这些都会报语法错误或静默失败。
-
BEFORE INSERT：只有NEW可读可写（可用于修改即将插入的值），OLD不可用 -
BEFORE UPDATE：NEW可写（改新值），OLD只读（原值） -
BEFORE DELETE：只有OLD可用，NEW不存在 - 注意：对
NEW.col赋 NULL 值可能触发后续 NOT NULL 约束失败，比触发器本身报错更晚出现
调试触发器的三步实操法（不用日志表也能看清）
MySQL 触发器不能直接 SELECT 输出到客户端，也不能用 PRINT，但可以用可控方式“漏出”中间状态。
- 第一步：在触发器开头加
INSERT INTO debug_log (msg, ts) VALUES (CONCAT('trigger fired, NEW.id=', NEW.id), NOW());，提前建好debug_log表（记得设ENGINE=InnoDB避免锁表） - 第二步：把可疑逻辑拆成独立
SET @var := ...，再用INSERT写入变量值，确认每一步计算是否符合预期 - 第三步：如果连
INSERT都被阻塞（比如触发器自己又调了另一个失败的触发器），改用INSERT ... SELECT绕过约束，或临时把触发器改成SELECT 'debug:', NEW.xxx——虽然语法报错，但错误信息里会带出你想看的值
触发器的错误不会单独隔离，它和主语句共享事务上下文，这点容易被当成“数据库bug”去排查。真正卡住的时候，先关掉触发器、再逐个打开，比对着错误码查文档更快。
