触发器会显著拖慢INSERT语句执行速度，因其同步阻塞特性导致主表写入必须等待触发器逻辑全部完成；实测显示含INSERT或SELECT的触发器可使耗时翻倍甚至更高。
触发器会显著拖慢 INSERT 语句执行速度
只要触发器里有 INSERT、UPDATE、SELECT 或调用函数，单条 INSERT 的耗时就可能翻倍甚至更高。MySQL 在执行触发器时是同步阻塞的——主表写入必须等触发器逻辑全部跑完才能返回成功。实测中，一个含 INSERT INTO log_table 的 BEFORE INSERT 触发器，让批量插入 1000 行的耗时从 80ms 增至 320ms；若触发器里再加一次 SELECT COUNT(*)，耗时直接跳到 650ms。
哪些触发器操作最伤性能
不是所有触发器逻辑都一样重。以下操作在实际压测中被证实对写入吞吐量影响最大：
-
INSERT/UPDATE其他表：触发器内写日志表、更新统计表，会引发额外事务开销和行锁竞争 -
SELECT查询非索引字段或大表：比如SELECT name FROM users WHERE id = NEW.user_id，但users.name没索引，每次插入都触发全表扫描式回表 - 调用自定义函数（尤其是含 SQL 的
DETERMINISTIC函数）：MySQL 不会缓存函数结果，每行都重算 - 使用
NEW.*字段做字符串拼接 +INSERT ... VALUES (CONCAT(...))：隐式类型转换或长文本处理会抬高 CPU 占用
替代触发器的轻量方案
如果只是为了记录变更或补全字段，多数场景下可绕过触发器：
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 应用层统一写入：在业务代码中用事务包裹主表
INSERT和日志表INSERT，比触发器更可控，还能批量合并日志写入 - 默认值 + 表达式列（MySQL 8.0.13+）：用
GENERATED ALWAYS AS替代简单计算字段，不参与写入路径，零运行时开销 - 异步消费 binlog：用
canal或Debezium抽取变更，解耦写入与衍生逻辑，适合审计、搜索同步等场景 - 延迟写日志表：把日志先写入内存表（
ENGINE=MEMORY）或 Redis，再由后台任务定时落盘
真要用触发器时的硬约束
若业务强依赖触发器（如金融类强一致性校验），务必守住这几条线：
- 只读操作必须走覆盖索引：例如
SELECT status FROM orders WHERE order_id = NEW.order_id，需确保(order_id, status)是联合索引 - 禁止在触发器里调用存储过程，尤其含循环或游标的——MySQL 触发器栈深度有限，易报错
ERROR 1422 (HY000): Explicit or implicit commit is not allowed in stored function or trigger - 避免
AFTER INSERT中修改新插入行（如UPDATE target_table SET updated_at = NOW() WHERE id = NEW.id），这会引发二次触发或死锁 - 批量插入时慎用
INSERT ... SELECT触发触发器：MySQL 对每行都单独执行触发器，哪怕源数据来自子查询
触发器不是不能用，而是它的“透明性”极具欺骗性——看起来只是加了几行逻辑，实际已把单次写入变成多表事务+多次索引维护+潜在锁等待。线上高频写入表上加触发器前，务必用真实数据集做 sysbench 或 mysqlslap 对比压测，而不是只看单条 SQL 的执行时间。
