生产环境MySQL触发器过多：性能与维护隐患

直接说结论：生产环境里触发器越多，越容易出长事务、死锁和主从延迟，而且问题藏得深，查都难查到。

它不是“可能有问题”，而是只要并发一上来、数据量一涨、逻辑稍复杂，就立刻拖垮写入性能——而且你看到的慢 SQL 日志里，根本不会显示触发器干了什么。

MySQL触发器导致事务时间不可控

触发器的本质是“寄生”在主 DML 事务里的，它没有自己的独立事务边界。INSERT 语句执行完，触发器里的 SELECT 或 UPDATE 没跑完，整个事务就得一直开着——锁不释放，undo log 无法 purge，binlog 也一直攒着。这就像你排着队办业务，但前面的人突然掏出三个表要填，整个队伍都得等他。

• 常见现象：SHOW PROCESSLIST 显示 Updating 或 Waiting for table metadata lock，但真正卡住的是触发器里那条没索引的 SELECT COUNT(*) FROM audit_log WHERE ...
• AFTER UPDATE 去更新 user_stats 表？那张表的行锁也被拖进同一事务，和其他路径形成死锁闭环
• 批量导入 10 万行，触发器逐行执行 → 事务持续几十秒，INFORMATION_SCHEMA.INNODB_TRX 里 TRX_ROWS_MODIFIED 瞬间飙高

触发器里的 SQL 完全逃过 EXPLAIN 和慢日志追踪

最让人头疼的是，你根本没法用常规手段定位触发器的问题。EXPLAIN INSERT INTO orders 不会展示触发器内任何语句；slow_query_log 只记主 SQL，不标触发器名，错误信息如 Deadlock found when trying to get lock 也不告诉你哪条触发器、哪一行代码惹的祸。这就像家里的水管漏水，但只显示总水表读数异常，具体哪一段漏了完全不知道。

• 想定位触发器耗时？只能翻 performance_schema.events_statements_history_long，但 SQL_TEXT 默认截断，长逻辑得人工拼
• SHOW CREATE TRIGGER 查定义要手动执行，没法集成进监控告警
• 空触发器也有 0.1–0.3ms 固定开销；一个含 SELECT ... FOR UPDATE 的触发器，5ms 就能让平均锁等待翻倍

高并发下触发器天然串行化写入链路

MySQL 触发器的执行机制是行级、同步、逐行调用。1 条 INSERT 触发 1 次，1000 行就是 1000 次——没有异步、不能批处理、绕不开事务边界。高并发场景下，这就相当于把一条单车道硬生生变成了单行道，所有车都得排队通过。

• LOAD DATA INFILE 带触发器？性能衰减线性增长，索引优化完全无效
• 多个触发器争抢同一张统计表（如 user_summary）主键 → 高概率 Deadlock found when trying to get lock
• 触发器数量超几十个时，metadata lock 等待明显上升，ALTER TABLE 都可能被卡住

替代方案比“优化触发器”更实际

与其费劲优化触发器，不如换个思路。真要自动同步或审计，应用层封装、GENERATED COLUMN、BINLOG 解析（如 Canal）都比硬塞触发器靠谱得多。

• 更新时间戳？用 updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，不用触发器
• 审计日志？别在 AFTER INSERT 里写 INSERT INTO audit_log，改用 Canal 抽取 binlog 异步落库
• 统计类字段？用应用层双写或定时任务覆盖更新，避免每行变更都触发计算
• 非用不可？只允许 BEFORE INSERT/UPDATE 做简单赋值，禁用 NOW()、RAND()，单触发器最多 1 条写入，目标表不能是当前表

最麻烦的从来不是触发器做了什么，而是它做了什么你根本看不见；最危险的也不是某条 SQL 慢，而是整条写入链路被它无声卡住——等你发现时，TPS 已经腰斩，主从延迟破百秒，而 slow log 还在安静地只记录那条“看起来很快”的 INSERT。