触发器中执行UPDATE性能差，因锁粒度大、日志膨胀、执行计划重编译；应改用应用层异步、INSTEAD OF触发器、分批处理或状态标记+后台清理。
触发器里做 UPDATE 就慢，别这么干
SQL Server 或 MySQL 里，UPDATE 触发器中再执行 UPDATE 其他表（尤其是大表），基本等于给自己埋雷。不是逻辑错，是锁粒度、日志膨胀、执行计划重编译三重叠加——单条更新可能毫秒级，批量改 10 万行时，触发器被调用 10 万次，每回都走一遍全链路。
实操建议：
- 把触发器里的业务逻辑抽出来，改用「应用层异步处理」或「定时批处理任务」，比如用消息队列收变更事件，后台服务聚合后统一更新
- 如果必须在数据库侧闭环，改用
INSTEAD OF UPDATE触发器，把原语句和附加逻辑合并成一条高效UPDATE ... JOIN，避免嵌套执行 - 禁用触发器临时跑批量：用
DISABLE TRIGGER+ 手动补逻辑，完事再ENABLE，但得确保幂等性和事务边界清晰
WHERE 条件没走索引，触发器一卡就是几十秒
触发器里常见写法：UPDATE t2 SET status = 'done' WHERE t2.id IN (SELECT id FROM inserted)。看着没问题，但 inserted 是内存表，没统计信息，SQL Server 容易选错执行计划；MySQL 8.0 前甚至不支持对 NEW/OLD 做索引提示。
实操建议：
- 显式建临时表并加索引：
SELECT id INTO #tmp_ids FROM inserted; CREATE INDEX ix_id ON #tmp_ids(id);，再拿它去 JOIN - 改用
EXISTS替代IN，尤其在 SQL Server 中更稳定：UPDATE t2 SET status='done' WHERE EXISTS (SELECT 1 FROM inserted i WHERE i.id = t2.id) - 检查目标表
t2.id是否真有索引——很多“慢”其实卡在主表没建好索引，不是触发器本身的问题
批量 UPDATE 触发器导致事务日志暴涨
一次更新 50 万行，触发器又顺带改了 3 张关联表，每张表的每一行变更都要记日志。简单算：50 万 × 4 表 × 每行 100 字节 ≈ 200MB 日志，还没算锁升级和 checkpoint 压力。
实操建议：
- 拆分批次执行，比如每次只
UPDATE TOP(5000)，配合WAITFOR DELAY '00:00:00.1'控制节奏，避免日志连续打满 - 确认数据库恢复模式：如果是
FULL，批量操作前手动打日志备份，否则LOG_BACKUP跟不上就会阻塞 - MySQL 用户注意：
binlog_format=ROW下同样会放大日志量，可考虑临时切MIXED（但得评估复制一致性风险）
触发器嵌套 + 递归调用引发死锁或超时
UPDATE t1 触发器改 t2 → t2 的触发器又改 t3 → t3 回头更新 t1，这种环形依赖在高并发下极易出现 deadlock encountered 或 timeout expired 错误。
实操建议：
- 用
TRIGGER_NESTLEVEL()（SQL Server）或@@NESTLEVEL（MySQL）在触发器开头加守卫：IF TRIGGER_NESTLEVEL() > 2 RETURN - 所有跨表修改统一走「状态标记 + 后台清理」模式：只在触发器里设个
is_dirty = 1，不真正改数据 - 检查是否启用了
RECURSIVE_TRIGGERS（SQL Server）或innodb_trx_rseg_n_slots相关参数，非必要就关掉
最麻烦的不是写不出触发器，是它在低流量时完全正常，一上生产批量就崩——因为锁、日志、执行计划全在数据量阈值附近拐弯。盯住 sys.dm_exec_query_stats 或 performance_schema 里的实际执行次数和平均耗时，比看代码更能定位问题根子。
