触发器本身不直接升级锁，但会因内部SQL未走索引、使用范围条件或逐行执行，导致实际锁住整段索引甚至全表；根本原因是隐式执行且锁行为不可见，需通过EXPLAIN确认索引命中并避免非主键/非唯一索引的WHERE条件。
触发器本身不会主动“升级锁”，但会让原本只锁几行的操作，变成锁住整段索引甚至全表——根本原因是它在主事务中隐式执行，且内部 SQL 没走索引或用了范围条件。
触发器里一句没索引的 UPDATE 就会锁全表
比如在 AFTER UPDATE 触发器里写：UPDATE stock_log SET status = 'done' WHERE sku_code = NEW.sku，而 sku_code 字段没有索引。InnoDB 就得扫描整个聚簇索引，对每行都加 X 锁。哪怕最终只改 1 行，也等于锁住了当前活跃数据段的所有行。
- 用
EXPLAIN FORMAT=TRADITIONAL模拟执行，确认type是const或ref，绝不能是ALL或index -
key字段必须非空，rows估算值要接近实际影响行数 - 补索引不是“优化”，而是避免锁爆炸的底线要求
WHERE 条件带函数或范围，间隙锁直接扩大到整个区间
例如：UPDATE stats SET total = total + 1 WHERE status = 'pending'。如果 status 只是普通二级索引（非唯一），在 RR 隔离级别下，InnoDB 会对所有 status = 'pending' 的记录加 next-key lock——这可能覆盖几十万行，还顺带锁住它们之间的间隙。
- 禁止在触发器中使用任何非主键/非唯一索引的
WHERE条件 - 真要按状态更新，先用主键查出 ID 列表，再
WHERE id IN (…)精确更新 -
WHERE UPPER(sku) = 'ABC'这类写法会让索引失效，退化成全表扫描加锁
批量操作触发器逐行执行，锁反复申请释放
MySQL 触发器是行级触发：一条 UPDATE orders SET status = 'shipped' WHERE user_id = 123 影响 1000 行，触发器就执行 1000 次。每次都要重新解析、加锁、释放——不是锁“升级”，而是锁被高频、重复地申请和释放，放大了竞争窗口。
- SQL Server 中误把
inserted当单行变量处理（如SELECT @id = id FROM inserted），也会导致同样问题 - 正确做法是集合操作：
UPDATE t2 SET status = 'done' FROM t2 INNER JOIN inserted ON t2.id = inserted.id - MySQL 没有
inserted伪表，但批量更新时仍要警惕触发器被调用次数与锁开销正相关
最危险的不是锁本身变大，而是你从应用日志里完全看不到这些锁的存在——INSERT INTO orders 报死锁，背后可能是触发器悄悄锁了 stock_log 和 audit_trail 两张表。排查时得进 SHOW ENGINE INNODB STATUS\G 的死锁图里找 executionStack，而不是只盯主 SQL。
