MySQL行级锁易引发死锁，因细粒度加锁+事务交叉顺序不一致形成循环等待；InnoDB通过死锁检测机制自动回滚代价小的事务来解决，预防需统一加锁顺序、避免无索引导致表锁、关闭间隙锁及缩短事务时间。
MySQL InnoDB 的行级锁并不能有效解决死锁难题——它恰恰是死锁最常发生的根源之一。
死锁在 InnoDB 中是正常且高频的现象，根本原因正在于行级锁的细粒度 + 并发事务交叉加锁的组合。真正起作用的不是“行锁避免死锁”，而是 InnoDB 的死锁检测机制（innodb_deadlock_detect）自动回滚代价小的事务，从而打破循环等待。
下面说清楚几个关键点：
行锁为什么反而容易引发死锁？
行锁粒度小，并不等于安全；它让多个事务能同时操作不同行，但一旦加锁顺序不一致，就极易形成环路：
- 事务 A 先更新
id=10，再尝试更新id=20 - 事务 B 先更新
id=20，再尝试更新id=10
此时 A 持有 10 的 X 锁等待 20，B 持有 20 的 X 锁等待 10 —— 典型的死锁。这种场景在高并发订单、库存、账户余额等业务中极其常见。
间隙锁和临键锁是死锁的隐形推手
在默认的可重复读（RR）隔离级别下，InnoDB 不只是锁住匹配的行，还会加 Gap Lock 或 Next-Key Lock。这意味着：
-
SELECT * FROM orders WHERE status = 'pending' FOR UPDATE可能锁住整个 status='pending' 的索引范围，而非单条记录 - 两个事务对同一二级索引字段做范围条件更新，哪怕操作的是不同行，也可能因间隙重叠而互相阻塞
- 这类“看不见的锁”比显式更新更难排查，线上死锁日志里大量出现
waiting for this lock to be granted却找不到对应 SQL
没有索引时，行锁直接退化成表锁
InnoDB 行锁生效的前提是 SQL 走索引。如果 WHERE 条件没命中任何索引（比如对无索引字段查询、或用了函数/隐式类型转换），InnoDB 就无法定位具体行，只能对全表所有聚簇索引记录加锁 —— 这就是事实上的表级锁：
- 一个
UPDATE users SET name='x' WHERE phone LIKE '%123%'（phone无索引）会锁全表 - 此时并发事务哪怕操作完全无关的用户，也会被阻塞，死锁概率陡增
- 用
EXPLAIN看执行计划，确认type是range/ref而非ALL，是最基本的避坑动作
真正缓解死锁的实操手段
靠“用行锁”本身没用，得从行为和配置入手：
- 统一加锁顺序：所有事务按相同字段（如主键升序）批量更新，避免交叉持有
- 缩短事务生命周期：把
SELECT ... FOR UPDATE放在事务靠后位置，减少锁持有时间 - 必要时降级隔离级别：将 RR 改为
READ COMMITTED，关闭间隙锁（innodb_locks_unsafe_for_binlog=ON已废弃，直接设隔离级别即可） - 监控死锁日志：
SHOW ENGINE INNODB STATUS\G中的LATEST DETECTED DEADLOCK段落，看具体哪两行 SQL 在争什么锁
死锁不是配置错了才发生，而是设计没对齐就必然发生。最容易被忽略的一点是：开发时只关注“SQL 能跑通”，却从不验证它实际锁了哪些索引、锁了多大范围 —— 这才是线上死锁频发的底层原因。
