触发器强制同步串行执行，1000行插入即触发1000次逻辑，每次1ms总耗1秒，tps从1000骤降至1；其共享事务上下文会隐式放大锁范围，易引发等待链与死锁。
触发器强制同步串行执行，1000行插入就等于1000次独立事务开销
MySQL触发器不是异步后台任务，而是和主 INSERT 共享同一事务、同一线程、同一锁上下文。批量插入 1000 行，就会触发 1000 次触发器逻辑——哪怕每次只耗 1ms，总延迟就是 1 秒，TPS 直接从 1000 掉到 1。
这不是“可能变慢”，是机制决定的硬性限制：BEFORE 或 AFTER 触发器都必须等它执行完，主语句才能提交。你无法通过调优配置绕过这点。
- 触发器里写
INSERT INTO log_table VALUES (NEW.id, NOW())，单次就增加 2–10ms 延迟 - 触发器中含
SELECT COUNT(*) FROM orders WHERE user_id = NEW.user_id，若没索引，每次都是全表扫描 - 跨库查询如
SELECT * FROM other_db.users WHERE id = NEW.user_id，会额外建立连接，无法复用当前事务
触发器内 SELECT 会隐式放大锁范围，引发等待链甚至死锁
你以为只是查个字段，实际在 RR 隔离级别下，SELECT ... FOR UPDATE 或普通 SELECT（带 gap lock 条件）都会持锁。比如触发器里一句 SELECT balance FROM accounts WHERE id = NEW.account_id，若 accounts.id 没索引，就会全表加锁；多个并发 INSERT 同一用户时，立刻排队。
更危险的是组合操作：触发器先查 user_profile 加 X 锁，再 UPDATE order_summary，而另一笔事务反向操作，就构成典型死锁闭环。
-
SHOW PROCESSLIST里大量线程卡在Updating或Waiting for table metadata lock，大概率是触发器锁扩散所致 - 监控
Innodb_row_lock_waits指标飙升，比慢日志更能定位真实瓶颈 - 所有触发器内
SELECT必须走覆盖索引，禁止JOIN、IN、OR、函数包裹字段（如UPPER(email)）
怎么确认 INSERT 变慢真是触发器导致的？别只看慢日志
慢日志里一条 INSERT INTO orders 耗时 80ms，不代表语句本身慢——可能 75ms 都花在触发器里。MySQL 没有原生 SQL Profiler，得靠 performance_schema 拆解时间片。
实操步骤：
- 确保
performance_schema已启用：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history', 'events_stages_history') - 执行一次插入后，查：
SELECT EVENT_NAME, TIMER_WAIT FROM performance_schema.events_stages_history WHERE NESTING_EVENT_ID IN (SELECT EVENT_ID FROM performance_schema.events_statements_history WHERE SQL_TEXT LIKE '%INSERT INTO orders%') ORDER BY TIMER_WAIT DESC LIMIT 5 -
TIMER_WAIT单位是皮秒，除以1e12才是秒数；别误读成毫秒
如果发现 statement/sql/select 或 statement/sql/insert 占比极高，且对应触发器里的 SQL，就坐实了问题来源。
替代方案不是“优化触发器”，而是彻底绕开它
想靠加索引、改写 SQL 让触发器“快一点”是徒劳的。只要它还在事务里同步执行，就永远是吞吐瓶颈。真正有效的路径只有一条：触发器只做最轻量的事——写一条变更记录到中转表，其余全部交给外部消费者。
- 触发器内只保留：
INSERT INTO sync_log (table_name, pk_value, op_type) VALUES ('orders', NEW.id, 'INSERT') - 用 Canal、Debezium 或自研服务监听 binlog，消费
sync_log并异步处理日志、统计、通知等逻辑 - 验证是否真解耦：关掉消费者服务，业务
INSERT是否照常不卡？能，才算成功 - 应用层统一写入（事务包裹主表 + 日志表）或 MySQL 8.0+ 的
GENERATED ALWAYS AS表达式列，更适合补全字段类需求
复杂点在于，很多人把“调用存储过程发 Kafka”当成异步——其实仍是同步阻塞。真正的异步必须满足两个硬条件：主 SQL 完全不感知下游动作；消费者连接与主事务完全隔离。
