生产环境触发器越多越易引发长事务、死锁和主从延迟，因其同步逐行执行、绑定主事务、逃逸监控且定位困难，应优先用应用层封装、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。
