为何生产环境下不建议在MySQL中使用过多的触发器？

生产环境触发器越多越易引发长事务、死锁和主从延迟，因其同步逐行执行、绑定主事务、逃逸监控且定位困难，应优先用应用层封装、Generated Column或Binlog解析替代。

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

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

触发器会让事务时间不可控

触发器不是独立事务，它被硬绑在主 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。