SQL 触发器性能优化与风险

触发器执行慢是因为同步阻塞，主sql需等待其完成；after insert比insert本身耗时，主因是触发器内含select/update、锁等待和i/o延迟。

触发器执行慢，查 AFTER INSERT 为什么比 INSERT 本身还耗时？

因为触发器是同步阻塞执行的，主 SQL 必须等它全部跑完才返回成功。尤其当触发器里有 SELECT、UPDATE 或跨表操作时，锁等待和 I/O 延迟会直接拖垮插入性能。

• 避免在触发器里做复杂查询：比如用 SELECT count(*) FROM orders WHERE user_id = NEW.user_id 统计——改用应用层缓存或异步更新
• 别在触发器里调用存储过程，除非你确认它只做轻量级逻辑；否则把逻辑拆到应用层更可控
• 如果必须查其他表，确保被查字段有索引，且尽量用主键或唯一键关联，避免全表扫描
• 用 EXPLAIN 看触发器隐式执行的语句计划，重点检查是否出现 using temporary 或 Using filesort

mysql 触发器修改 NEW 字段无效？

在 BEFORE INSERT 或 BEFORE UPDATE 触发器里可以安全赋值给 NEW.column_name，但 AFTER 类型触发器中修改 NEW 没有效果——数据已写入表，再改只是改了临时变量。

• BEFORE INSERT 中可设默认值：SET NEW.created_at = NOW();
• BEFORE UPDATE 中可校验并拦截：if NEW.status NOT IN ('pending', 'done') THEN signal SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid status'; END IF;
• AFTER 触发器只能读 NEW 和 OLD，不能写；想“反向更新”原表？那是设计错误，该用事务+应用逻辑重做

触发器导致死锁或主从不一致？

常见于多个触发器嵌套、或触发器内又触发另一个表的触发器（比如 A 表插入触发 B 表更新，B 表更新又触发 C 表插入）。MySQL 不支持触发器事务隔离级别控制，且 binlog 记录的是原始语句而非最终结果。

• 主从复制用 STATEMENT 格式时，触发器在从库不会重放——但 ROW 格式下会记录所有变更行，相对安全
• 禁止在触发器里做 INSERT INTO ... SELECT 这类可能锁多行的操作，极易引发间隙锁冲突
• 避免触发器调用 UUID()、NOW() 等非确定性函数，否则主从时间差会导致数据不一致
• 上线前务必在从库开启 log_slave_updates 并用 SHOW SLAVE STATUS 检查 Seconds_Behind_Master 是否突增

想替代触发器，但又不想改应用代码？

真要兼顾解耦和可控性，优先考虑数据库代理层或 CDC 工具，而不是硬扛触发器。触发器不是“自动化的银弹”，它是黑盒、难测、难调试的隐式逻辑。

• 用 Debezium + kafka 捕获 binlog 变更，在外部服务里处理业务逻辑，失败可重试、可监控、可灰度
• 如果只是审计日志，直接开 general_log 或用 PERFORMANCE_SCHEMA 抓取 events_statements_history
• 某些场景下，用 GENERATED COLUMN（MySQL 5.7+）代替简单计算字段，比触发器更轻量、无副作用

触发器最危险的地方不是它慢，而是它藏在背后不动声色地改数据——出问题时，没人记得它存在。