触发器在高并发写入时会成为性能瓶颈，因其同步阻塞式执行且无法并行，加剧锁等待、事务延迟和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+ 支持）
如果必须保留触发器，请严格约束其行为
不是所有触发器都一样危险。以下做法能缓解但无法根除并发压力：
