触发器必然拖慢INSERT，因其在事务内同步逐行执行且共享锁上下文；修复只能剥离非必要逻辑或移出事务，禁用跨表查询、无索引条件、非确定性函数及反向更新。
启用 SQL 触发器后接口响应变慢，基本不是“触发器写得不够好”，而是它把本该异步或前置处理的逻辑，硬塞进了主事务里同步执行。只要触发器里出现一次跨表查询、一次无索引条件、一次非确定性函数调用，单条 INSERT 就可能从 0.5ms 拉到 15ms；批量插入时，延迟不是叠加，是乘性爆炸。
触发器让 INSERT 变慢的根本原因
MySQL / PostgreSQL / SQL Server 的触发器（尤其是 FOR EACH ROW）都在事务内逐行同步执行。这意味着：
- 每插入一行，就调用一次触发器函数，带来上下文切换开销
- 触发器内所有语句共享主事务的锁上下文——哪怕只是查一张日志表，也可能锁住整张表
- 事务持续时间被拉长，
innodb_row_lock_time上升，Lock wait timeout exceeded错误频发 - 应用层感知的是“接口超时”，但根源是数据库事务卡在触发器某条
SELECT或UPDATE上
哪些触发器操作会立刻拖垮写入性能
以下行为只要存在一项，就足以让写入延迟失控，且无法靠加索引或调参数修复：
-
SELECT查询其他表（尤其WHERE user_id = NEW.user_id但accounts.user_id没索引） -
WHERE UPPER(email) = UPPER(NEW.email)—— 函数包装字段，索引失效 -
AFTER INSERT中反向UPDATE order_summary SET total = total + NEW.amount—— 与主表行锁竞争，8.0+ 极易报Deadlock found when trying to get lock - 调用自定义函数如
GET_USER_RANK()，每次调用隐式开启子事务 - 使用
RAND()、UUID()、NOW()等非确定性函数（破坏主从一致性，且求值不可缓存）
怎么确认真是触发器在拖慢接口
别只看慢查询日志里那条 INSERT 耗时高——得定位到触发器本身。MySQL 没有 SQL Profiler，但可用 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 your_table%') ORDER BY TIMER_WAIT DESC LIMIT 5 -
TIMER_WAIT单位是皮秒，除以10^12才是秒数；如果看到statement/sql/select占比高，基本就是触发器里的查询在吃时间
真正有效的修复路径不是优化，而是剥离
触发器不是性能瓶颈的“症状”，它是错误架构选择的“诊断书”。修复方向只有两个：
- 必须保同步的，只留最轻量逻辑：
SET NEW.created_at = NOW()、SIGNAL校验、REPLACE清洗字段 - 所有跨表查询、更新统计、写日志、发通知、调外部 API，一律移出触发器：
→ 改由应用层异步发 MQ
→ 或监听 binlog（用canal/maxwell）消费
→ 真要保留中转，用极简INSERT INTO trigger_queue (id, table_name) VALUES (NEW.id, 'orders')，这张表引擎选MEMORY或精简InnoDB
最容易被忽略的一点：哪怕你把触发器里所有查询都加上了覆盖索引，只要它还在事务里同步执行，就仍在承担锁继承和上下文切换的硬开销——这不是优化能绕过的，是设计边界问题。
