触发器复用主事务上下文，其DML延长主事务X锁生命周期，易引发死锁且排查困难；优化需聚焦索引、锁提示与执行计划，根本解法是异步剥离。
触发器不会开启新事务，它直接复用主事务上下文——所有它执行的 DML 都在同一个事务里加锁，直到 COMMIT 或 ROLLBACK 才释放。
触发器内 UPDATE/INSERT 实际延长的是主事务的 X 锁生命周期
你执行 UPDATE orders SET status = 2 WHERE id = 1001，表面只锁 orders 行；但若该表有 AFTER UPDATE 触发器去更新 user_points 和 audit_log，那么这三张表的对应行都会被加上 X 锁，并且这些锁会一直挂着，直到整个事务结束。
常见错误现象：Deadlock found when trying to get lock 报错堆栈显示的是触发器里的 UPDATE audit_log SET ... WHERE order_id = NEW.id，但应用日志只记了主表语句，排查时极易漏掉触发器这一环。
- 检查方法：对触发器中每条 DML，用真实参数跑
EXPLAIN FORMAT=TRADITIONAL，确认type不是ALL或index，key字段非NULL，rows估算接近实际影响行数 - 若发现执行计划含
Using where; Using index condition缺失，立刻补索引——否则哪怕只改一行，也可能因全表扫描锁住整张表活跃数据段 - SQL Server 中尤其注意伪表（
inserted/deleted）误用：写成SELECT @id = id FROM inserted是单行取值，批量更新时触发器被调用 N 次；应改用集合操作：UPDATE t2 SET status = 'done' FROM t2 INNER JOIN inserted i ON t2.order_id = i.id
为什么 READ COMMITTED SNAPSHOT 对触发器死锁基本无效
READ COMMITTED SNAPSHOT 只改变 SELECT 的读行为（启用版本控制），对触发器里执行的 UPDATE/INSERT/DELETE 完全不生效——那些语句仍照常申请 X 锁、U 锁，锁时间与粒度毫无变化。
真正起作用的是锁提示和索引结构：
- 在触发器内部的 DML 末尾加
WITH (ROWLOCK)，可防止页锁或表锁升级（前提是数据分布合理、无热点页） - 高频被触发器更新的目标表（如日志表），禁用
AUTO_UPDATE_STATISTICS_ASYNC，避免统计信息异步刷新与 DML 抢锁 - 检查被触发器更新的表上是否存在“非对称索引”：比如两个非聚集索引都
INCLUDE了varchar(max)字段，会导致索引页变宽、锁升级概率飙升；把大字段换成varchar(400)或移出INCLUDE常能立竿见影
最有效的缓解动作不是优化触发器，而是剥离它
当写入延迟已明显升高（如单条 INSERT 从 0.3ms 拉到 12ms），说明你正在用同步机制解决异步问题——这不是“能不能优化”的问题，而是架构级误用。
必须立刻停用以下操作（只要出现一次就足以失控）：
-
SELECT查询其他表（尤其是带WHERE status = NEW.status AND created_at > ...这类未覆盖索引的条件） -
UPDATE或INSERT INTO ... SELECT跨表写入（如订单插入后同步更新客户积分） - 调用自定义函数（如
GET_USER_RANK()）、非确定性函数（NOW()、RAND()）或外部调用（HTTP、存储过程通知服务）
替代路径分层落地：
- 强一致场景 → 改用
ON DUPLICATE KEY UPDATE或MERGE，把逻辑压进单语句 - 秒级延迟可接受 → 触发器只做轻量写入（如
INSERT INTO trigger_queue (table_name, pk, event_type)），由外部消费者（Kafka consumer / Maxwell / 轮询 job）异步处理
真正容易被忽略的一点：触发器失败会直接导致主操作回滚，而它的执行路径不可见、不可监控、无法打点——线上一旦出问题，你看到的永远是“某条简单 INSERT 超时”，而不是“它背后悄悄锁了四张表并等了 48 秒”。
