触发器在高并发写入时会成为性能瓶颈，因其同步阻塞式执行且无法并行，加剧锁等待、事务延迟和CPU占用，应优先采用业务层收口、异步解耦或批量绕过等替代方案。
触发器在高并发写入时会成为性能瓶颈
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%，说明已成瓶颈
触发器的“隐形成本”不在代码行数，而在它强制把本可异步或批处理的逻辑，绑死在每个事务的临界区内。越早把它从热路径里摘出来，后续扩容越省力。
