触发器未执行的首要原因是UPDATE语句未实际修改数据导致跳过，其次需检查SHOW WARNINGS获取触发器内真实错误；BEFORE/AFTER时机、跨库表名前缀、事务回滚影响及禁止SELECT返回结果集也是关键排查点。
触发器没执行？先确认 AFTER 和 BEFORE 的时机是否匹配操作
MySQL 触发器不会“自动监听所有变更”，它只在明确指定的 DML 事件（INSERT、UPDATE、DELETE）发生时，按定义的时机（BEFORE 或 AFTER）执行。常见误判是以为改了某张表的字段，触发器就该响，结果发现根本没走。
-
BEFORE INSERT只在插入前触发，可用于修改新行值（如设默认时间、校验字段），但此时NEW.id还未生成（自增主键），不能依赖它做关联查询 -
AFTER UPDATE才能安全读取更新后的完整行，但注意：如果 UPDATE 语句实际没修改任何字段（比如SET name = name），MySQL 8.0+ 默认跳过触发器（受sql_mode中STRICT_TRANS_TABLES和NO_UNSIGNED_SUBTRACTION等影响） - 用
SELECT @@sql_mode;检查当前模式，尤其留意是否含STRICT_TRANS_TABLES—— 它会让“无效更新”静默失败，连触发器都不进
触发器报错却没提示？检查 SHOW WARNINGS 和错误日志级别
触发器内 SQL 报错（比如 INSERT INTO 目标表不存在、字段类型不匹配），MySQL 默认不会把错误抛给客户端，而是让整个 DML 语句失败，并可能只返回模糊的 ERROR 1452 (HY000): Cannot add or update a child row 类提示，根本看不出是触发器里崩的。
- 执行完疑似触发失败的
INSERT/UPDATE后，立刻执行SHOW WARNINGS;，常能看到触发器内部的真实错误，比如Unknown column 'xxx' in 'field list' - 确保 MySQL 错误日志开启（
log_error配置项），并设为log_error_verbosity = 3，否则触发器内的警告会被忽略 - 避免在触发器里写
SELECT（除非接INTO变量），MySQL 5.7+ 会直接报错ERROR 1415 (0A000): Not allowed to return a result set from a trigger
跨库操作失效？验证触发器中表名是否带库名前缀
触发器定义在哪个库，它的作用域默认就限于那个库。如果触发器里要操作其他库的表（比如记录日志到 sys_log 库），必须显式写全路径，否则 MySQL 会去当前库找表，找不到就静默失败或报错。
- 错误写法：
INSERT INTO audit_log VALUES (...);→ 只在触发器所在库搜audit_log - 正确写法：
INSERT INTO sys_log.audit_log VALUES (...);→ 明确指定库名 - 注意权限：执行触发器的用户必须对目标库表有对应权限（如
INSERT ON sys_log.audit_log），仅对原表有权限不够 - 不要用变量拼库名（如
CONCAT(@db_name, '.audit_log')），MySQL 触发器不支持动态库名
事务回滚导致触发器“白执行”？理解触发器和事务的绑定关系
触发器不是独立进程，它和宿主 DML 语句共用同一事务。一旦主语句因异常回滚，触发器里做的所有事（哪怕已写入另一张表）也会一起回滚 —— 这不是 bug，是 ACID 的必然表现，但容易让人误以为“触发器没生效”。
- 典型陷阱：在
AFTER INSERT里往日志表写记录，然后主事务因为外键约束失败而回滚 → 日志表数据消失，看起来像触发器没跑 - 想留痕？只能用非事务型存储引擎（如
MyISAM表），但代价是失去一致性保障；或者改用应用层异步写日志 - 调试时可在触发器开头加
INSERT INTO debug_log VALUES (NOW(), 'trigger fired');并确认该表是MyISAM，才能看到“是否真触发”
UPDATE 语句没真正变更数据时触发器被跳过，以及错误藏在 SHOW WARNINGS 里——这两处不主动查，几乎不可能定位。 
