<p>先查触发器是否存在且启用：SELECT * FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'your_trigger_name'; 确认STATUS为ENABLED；再排除ERROR 1442（禁止修改自身表）、sql_mode非严格导致静默失败、事件类型与操作不匹配、主从不一致等常见原因。</p>
触发器查不到、不执行，先确认它是不是真存在且已启用
MySQL 不会主动告诉你触发器被禁用了，也不会在 SHOW TABLES 里列出它——它只藏在 information_schema.TRIGGERS 里。很多“没反应”其实只是触发器压根没生效。
- 用
SELECT * FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'your_trigger_name';查是否存在、是否在目标库表上 - 检查
STATUS字段：值为ENABLED才算启用；若为DISABLED，需执行ALTER TRIGGER your_trigger_name ENABLE; -
SHOW TRIGGERS LIKE 'table_name';更快，但只返回当前数据库的触发器，跨库要切库再查 - 注意：MySQL 8.0+ 支持
DISABLE，但低版本（如 5.7）不支持该语法，禁用只能靠删掉重建
ERROR 1442 报错：不能在触发器里改自己这张表
这是最典型的硬性限制，不是 bug，是 MySQL 的设计铁律：BEFORE 或 AFTER 触发器中对「正在被操作的同一张表」做 INSERT/UPDATE/DELETE，必然触发 ERROR 1442 (HY000)。
- 常见诱因：想在
BEFORE INSERT里查主键最大值再自增赋值；或在AFTER UPDATE里更新本表统计字段 - 不能靠加事务、延迟、子查询绕过——MySQL 在解析阶段就拒绝这类语义
- 可行替代方案：
INSERT ... ON DUPLICATE KEY UPDATE合并逻辑；或把写操作挪到应用层，用单条 SQL 完成；或改用临时表中转（CREATE TEMPORARY TABLE+INSERT INTO ... SELECT） - 特别注意：调用的存储函数如果内部含对本表的修改，也会连带触发 ERROR 1442
日志静默失败？检查 sql_mode 和错误日志配置
触发器失败经常“没报错也没效果”，本质是 MySQL 默认容忍部分异常——比如字段类型不匹配、NEW.col 引用空值、SELECT INTO 没结果，都可能只记警告不中断执行。
- 确认是否启用了严格模式：
SELECT @@sql_mode;中必须含STRICT_TRANS_TABLES，否则多数数据问题会静默截断或设默认值，触发器看似运行实则逻辑跳过 - 打开详细错误日志：
SET GLOBAL log_warnings = 2;（MySQL 5.7+），并确认log_error配置指向可读路径（如/var/log/mysql/error.log） - 在触发器里加日志：建一张独立的
debug_log表（千万别用被触发的表！），用INSERT INTO debug_log VALUES (NOW(), 'in_trigger', 'id=123');记录关键节点 - 注意：从库不会执行触发器，所有日志和效果只存在于主库——别在从库上测触发器是否“生效”
触发器定义正确但就是不跑？重点核对事件类型与数据变更细节
触发器绑定的是「语句级事件」，不是「数据变化结果」。哪怕 SQL 语法合法、表结构匹配，也可能因细微条件不满足而跳过。
-
BEFORE UPDATE不会在字段值实际未变时触发（例如UPDATE t SET name='a' WHERE id=1;，但当前 name 就是 'a'）——MySQL 优化跳过，触发器也不执行 -
INSERT触发器对INSERT IGNORE或REPLACE仍会触发，但对LOAD DATA INFILE默认不触发（除非显式开启init_connect或用事件调度器中转） - 检查
SHOW CREATE TRIGGER trigger_name;输出，确认EVENT_MANIPULATION（INSERT/UPDATE/DELETE）、ACTION_TIMING（BEFORE/AFTER）、EVENT_OBJECT_TABLE三者完全匹配你的操作意图 - 跨库操作（如
INSERT INTO other_db.t2）失败时，错误常只出现在错误日志，客户端无提示，容易误判为“没触发”
触发器不是黑盒，它的边界非常清晰：不能碰自己表、不响应静默变更、不跨主从传播、不兼容某些语句。真正卡住的时候，往往不是逻辑多复杂，而是漏看了 information_schema.TRIGGERS 里的 STATUS，或者忘了主库从库根本不是一回事。
