触发器在高并发写入时会成为性能瓶颈
MySQL 触发器本身不是原子操作的“加速器”，而是同步阻塞式执行逻辑。每次
INSERT/
UPDATE/
DELETE触发时，触发器代码会串行运行在同一条事务线程中，无法并行化。这意味着：高并发写入场景下，触发器实际放大了锁等待、事务延迟和 CPU 占用。
常见错误现象包括：
慢查询日志里大量出现Trigger execution耗时（可通过
performance_schema.events_statements_history_long查看） 主从延迟突增，尤其在批量导入或促销写入高峰时
SHOW PROCESSLIST中大量线程卡在
Updating或
Executing trigger状态
替代方案比优化触发器更实际
触发器逻辑一旦复杂（比如调用函数、查多张表、写日志表），就很难通过索引或语句改写来提速。与其花时间压测
BEFORE INSERT是否比
AFTER INSERT快 2ms，不如直接换架构： 业务层统一收口：把原本放在
BEFORE UPDATE中的字段校验/补全逻辑，移到应用代码中处理 异步解耦：将审计、统计类逻辑从触发器剥离，改用
binlog解析（如 Canal、Debezium）或写入消息队列 批量操作绕过触发器：对大批量数据导入，显式使用
SET SQL_LOG_BIN = 0（仅限从库）或临时禁用（
ALTER TABLE ... DISABLE TRIGGER，MySQL 8.0.23+ 支持）
如果必须保留触发器，请严格约束其行为
不是所有触发器都一样危险。以下做法能缓解但无法根除并发压力：
只读操作优先：触发器内避免SELECT ... FOR UPDATE或更新其他表；若必须查，确保被查表有覆盖索引，且不引发锁升级 禁止调用存储函数：尤其是含
SELECT或循环的函数，会显著拖慢事务提交速度 日志类写入改用
INSERT DELAYED（已弃用）或更稳妥的方案——写入内存表（
ENGINE=MEMORY）再由后台定时刷出 检查
innodb_thread_concurrency和
innodb_flush_log_at_trx_commit配置，避免触发器加剧刷盘争用
测试触发器并发影响不能只看单条SQL
用
sysbench或
mysqlslap测单条带触发器的
INSERT，结果往往误导。真实瓶颈出现在锁竞争和事务排队上： 模拟并发时，至少启用 32+ 线程，并持续运行 5 分钟以上，观察
Innodb_row_lock_waits和
Threads_running峰值 开启
performance_schema后，查
events_waits_summary_by_thread_by_event_name，重点关注
wait/synch/mutex/innodb/...和
wait/io/file/innodb/...类型耗时 对比关闭触发器前后的
QPS和
avg_latency_us，若下降超 15%，说明已成瓶颈
触发器的“隐形成本”不在代码行数，而在它强制把本可异步或批处理的逻辑，绑死在每个事务的临界区内。越早把它从热路径里摘出来，后续扩容越省力。
