SQL触发器本身不直接导致死锁，但因其在主事务中隐式执行、共享事务ID和锁生命周期，会将单条SQL扩展为“主语句+多条触发逻辑”的复合锁操作；只要触发器内含UPDATE、SELECT FOR UPDATE或跨表DML，死锁概率即陡增。
SQL触发器本身不直接导致死锁，但它在主事务中隐式执行、共享同一事务ID和锁生命周期，会把单条SQL变成“主语句 + 多条触发逻辑”的复合锁操作——只要触发器里有UPDATE、SELECT FOR UPDATE或跨表DML，死锁概率就陡增。
怎么看死锁日志里有没有触发器参与
死锁发生后立刻执行SHOW ENGINE INNODB STATUS\G（MySQL）或查sys.dm_exec_requests + sys.dm_tran_locks（SQL Server），重点盯三处：
- 在
LATEST DETECTED DEADLOCK区块里找INSERT INTO orders后紧跟着UPDATE audit_log这类连续操作痕迹——这就是触发器执行堆栈 - 看
TRANSACTION段的mysql tables in use 2, locked 2：数字大于1表明涉及多表，大概率有触发器介入 - 比对
HOLDS THE LOCK(S)和WAITING FOR THIS LOCK TO BE GRANTED中的表名，如果其中一把锁落在t_log、audit_history这类日志表上，基本坐实是触发器行为
为什么触发器内UPDATE同一张表会死锁
看似安全的“自己改自己”，在InnoDB中极易触发循环等待：主事务已对NEW.id所在行持X锁，触发器再发一条UPDATE t1 SET status = 'done' WHERE id = NEW.id，就是二次申请同一行锁。
- 正确做法是用
SET NEW.status = 'done'在BEFORE触发器中直接赋值，不走额外SQL - 若需更新多字段（如订单状态+子表计数），必须剥离出触发器，交由应用层异步完成
- 真要在数据库侧维护统计值，可用
INSERT INTO summary_log写日志表（引擎选BLACKHOLE），再由定时任务批量聚合
怎么验证触发器里的DML是否走索引
触发器里一条没走索引的UPDATE product_stock SET qty = qty - 1 WHERE sku_code = 'ABC123'，在RR隔离级别下可能升级为全表间隙锁；而另一事务按相反顺序操作，ABBA锁序瞬间形成。
- 对触发器内每条DML，用真实参数模拟执行并加
EXPLAIN FORMAT=TRADITIONAL，确认是否走了预期索引 - 所有读操作必须命中覆盖索引：用
EXPLAIN确认type是const或ref，不能是ALL或index - 禁用
WHERE status = 'pending'这类范围条件，它会触发gap lock；统一用主键或唯一索引更新
真正危险的不是触发器存在，而是它让锁路径变得不可见——你很难从应用日志里看出某次INSERT背后悄悄锁了三张表。排查时别只盯错误码1205，得进死锁图XML里找executionStack里的触发器名；优化时也别幻想靠改隔离级，得盯着每条DML的实际执行计划和锁粒度。
