触发器强制逐行执行导致批量update性能崩溃，10万行更新引发10万次锁竞争与wal写入，tps骤降至1；根本解法是绕过触发器，改用生成列、binlog解析或禁用触发器。
触发器强制逐行执行，批量UPDATE变成串行瓶颈
MySQL 对 UPDATE t SET x = 1 WHERE id IN (1,2,3,10000) 这类语句不会“整体触发一次”，而是对每一行单独执行一遍触发器逻辑。哪怕触发器只有一行 UPDATE stats SET cnt = cnt + 1 WHERE type = NEW.type，10 万行更新就等于 10 万次独立事务、10 万次锁申请、10 万次 WAL 写入。TPS 从 1000 直接掉到 1 不是异常，是机制必然。
- SHOW PROCESSLIST 中大量线程卡在
Updating状态，不是卡在主 SQL，而是卡在触发器内 SQL - EXPLAIN 完全不显示触发器逻辑，优化主语句毫无意义
- performance_schema.events_statements_history_long 可查到含
TRIGGER字样的事件，平均耗时随行数线性上升
触发器内 UPDATE 扩大锁范围，引发等待链与死锁
触发器和主 SQL 共享同一事务上下文，它里面任何一句 UPDATE 或 SELECT ... FOR UPDATE 都会把原本只该锁当前行的事务，额外拖进其他表的锁竞争中。比如主语句更新 orders 行，触发器再去更新 stats 表，而另一路请求反着来（先更新 stats 再更新 orders），Deadlock found when trying to get lock 几乎必然发生。
-
INFORMATION_SCHEMA.INNODB_TRX和SHOW ENGINE INNODB STATUS显示阻塞源是触发器，但 trx_query 只显示主 SQL - 若
stats(type)没索引，UPDATE stats SET cnt = cnt + 1 WHERE type = NEW.type会升级成表级锁，且持续到整个事务提交 -
Innodb_row_lock_waits指标飙升，但 slow_query_log 里找不到对应慢 SQL——因为触发器耗时不单独计时
触发器内关联 UPDATE 让 WAL 和 IO 压力翻倍
批量写入本身已密集刷 WAL，触发器再同步更新关联表，等于给日志系统加压两层：UPDATE orders 生成约 50MB WAL，若触发器再更新两张审计表，每张每行写 100 字节日志，额外增加 100MB WAL。IO 随机化严重，innodb_file_per_table=ON 下还会产生大量 .ibd 文件碎片写入。
- sys.dm_io_virtual_file_stats（SQL Server）或
Innodb_os_log_written（MySQL）指标会异常凸起 - checkpoint 频率被迫升高，进一步抢占 I/O 带宽，形成恶性循环
- 禁用触发器后跑同样批量 UPDATE，
io_stall_write_ms可下降 10 倍以上
替代方案必须绕过触发器执行路径，而非优化它
所有“给触发器加索引”“拆函数”“缓存查询结果”的尝试都无效，因为问题根源不在写得不够好，而在于它本就不该承担批量场景下的逻辑分发职责。真正有效的办法是让 SQL 本身不走触发器逻辑：
- 字段自动填充改用生成列：
updated_at DATETIME AS (NOW()) STORED（MySQL 8.0+） - 统计类变更移出事务：用 Canal 解析 BINLOG，异步更新；或应用层发 Kafka 消息，由消费者聚合
- 临时禁用触发器做批量操作：
ALTER TABLE t1 DISABLE TRIGGER trigger_name（MySQL 8.0.19+） - 审计字段如
created_by必须由应用层显式传参，禁止依赖@session_var或CURRENT_USER()
最危险的不是触发器慢，而是它把锁、WAL、事务生命周期全绑死在一条语句上，且错误难以定位——你看到的 INSERT 成功了，但实际被触发器悄悄回滚；你看到的 QPS 掉了，但慢日志里空空如也。
