触发器执行会拖慢 INSERT/UPDATE/DELETE 吗
会，而且影响是同步、阻塞式的。MySQL 触发器在对应 DML 语句的指定时机（
BEFORE或
AFTER）立即执行，属于事务的一部分：只要触发器里有耗时操作（比如复杂查询、写日志表、调用
SELECT ... FOR UPDATE），整个原语句就会卡住，直到触发器执行完。
常见拖慢场景包括：
BEFORE INSERT中对另一张大表做
SELECT COUNT(*)校验
AFTER UPDATE中向日志表插入多条记录且日志表无主键或索引 触发器内调用存储函数，而该函数内部又含循环或嵌套查询
如何定位触发器是否成为性能瓶颈
不能只看慢查询日志——它默认不记录触发器内部语句。需组合以下手段：
开启performance_schema并启用相关消费者：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_statements_%';查
performance_schema.events_statements_history_long，过滤
SQL_TEXT含
TRIGGER或目标表名的记录 在触发器开头加
SELECT NOW(), CONNECTION_ID()到调试表，配合
SHOW PROCESSLIST观察长时间运行的线程 临时禁用触发器（仅测试环境）：
ALTER TABLE tbl_name DISABLE TRIGGER trigger_name;对比 DML 耗时变化
触发器内哪些操作最伤性能
不是所有 SQL 在触发器里都等价。以下操作应严格避免：
在BEFORE触发器中修改
NEW字段后，又对同一字段重复赋值（MySQL 不优化冗余赋值） 用
INSERT INTO log_table SELECT ... FROM big_table写日志——应改为单行
INSERT或异步落库 触发器中调用
SLEEP()、
USER()、
UUID()等非确定性函数（影响并行复制和从库回放） 对被触发表自身做 DML（如
AFTER UPDATE中再
UPDATE当前表），可能引发递归或死锁
关键原则：触发器逻辑必须轻量、确定、无副作用。超过 3 行有效 SQL 的触发器，就该重新评估设计。
替代触发器的更高效方案有哪些
多数业务场景下，触发器不是唯一解，甚至不是最优解：
数据一致性校验 → 改用CHECK约束（MySQL 8.0.16+）或应用层预检 审计日志 → 应用层统一埋点 + 异步写入 Kafka / Redis / 日志服务，避免阻塞主流程 级联更新 → 用应用层事务控制，或改用外键
ON UPDATE CASCADE（注意仅支持
InnoDB） 生成派生字段（如
full_name）→ 改为生成列（
GENERATED COLUMN），由 MySQL 自动维护
真正需要触发器的场景极少：比如强制记录某张核心表的物理删除时间（
DELETE无法被外键捕获），且不允许应用层参与。这种情况下，务必给日志表加好主键和时间字段索引，并限制触发器只做
INSERT单行操作。
