MySQL触发器导致大批量写入性能下降，因其强制同步逐行执行、放大锁竞争且无法绕过，1000行更新即触发1000次逻辑，TPS断崖式下跌；应禁用触发器，改用生成列、应用层处理或异步解耦。
因为触发器强制同步执行、逐行调用，且锁持有时间不可控——它把毫秒级的 INSERT 变成串行化事务，TPS 从 1000 直接掉到 1 不是异常，而是机制必然。
触发器让批量写入彻底失去并发能力
MySQL 对 INSERT INTO t VALUES (...), (...), ... 或 UPDATE t SET x=1 WHERE id IN (1,2,3,...) 这类语句，不会“整体触发一次”，而是对每一行单独跑一遍触发器逻辑。1000 行 = 1000 次触发器执行，哪怕每次只耗 1ms，总延迟就是 1 秒。
-
AFTER INSERT里哪怕只有一行INSERT INTO log_table VALUES (NEW.id, NOW())，也会让主语句多等 2–10ms（取决于磁盘 IO 和锁竞争） - 触发器内含
SELECT COUNT(*) FROM events WHERE user_id = NEW.user_id，而events(user_id)没索引？那就是全表扫描 + 行锁阻塞其他写入 - 用
mysqlslap -q "INSERT INTO orders"压测出 0.5ms，不代表真实场景——真正的瓶颈在锁排队，Innodb_row_lock_waits飙升才暴露真相
锁范围被触发器悄悄放大
触发器和主 SQL 共享同一事务上下文，它里面任何一句 SELECT ... FOR UPDATE 或 UPDATE，都会把原本只该锁订单行的事务，额外拖进其他表的锁竞争中。
-
BEFORE UPDATE里查配置表：SELECT value FROM config WHERE key = 'rate_limit'→ 每次更新都重查，O(1) 变 O(n) -
AFTER INSERT里更新用户表：UPDATE users SET last_order_time = NOW() WHERE id = NEW.user_id→ 主事务锁订单行，触发器又去锁users行，另一条路径反着来，立刻触发Deadlock found when trying to get lock -
SHOW PROCESSLIST只显示Updating或Executing trigger，不标具体触发器名；EXPLAIN完全不展示触发器内 SQL，你优化了主语句，却对里面三条嵌套SELECT一无所知
空触发器也有固定开销，且无法绕过
哪怕触发器 body 是空的，或只写 SET @x = 1，MySQL 仍需完成解析、权限检查、上下文切换等动作，实测带来 0.1–0.3ms 固定延迟。更麻烦的是，SET SQL_LOG_BIN = 0 可跳过 binlog，但无法跳过触发器执行——它就是事务的一部分。
- 触发器内调用
UUID()、NOW()、RAND()等非确定性函数，在高并发下争抢系统资源，单次增加 0.3–0.8ms - 触发器里写游标？每次触发都重新编译、结果集全加载进内存、
FETCH必须串行等待，还极易引发Waiting for table metadata lock -
LOAD DATA INFILE时触发器逐行调用，性能衰减呈线性增长，索引优化完全无效
最危险的不是触发器做了什么，而是它做了什么你根本看不见；最麻烦的不是它慢，而是你连它在哪慢都很难确认——slow log 里只记 INSERT INTO orders，performance_schema.events_statements_history_long 的 SQL_TEXT 字段还默认截断，长逻辑得人工拼接。
