innodb行锁升级为表锁是因未命中索引导致全表扫描并加锁。常见原因包括无索引、索引失效、or连接非组合索引、大范围select…for update；间隙锁和临键锁在rr级别防幻读但扩大锁范围；唯一等值查询仅加记录锁，非唯一索引等值查询仍加临键锁；insert会检查间隙锁，易引发死锁；减少冲突需统一访问顺序、缩短事务、降级隔离级别或监控死锁日志。
InnoDB 的行锁为什么有时会升级成表锁
InnoDB 默认加的是行级锁，但锁的粒度实际取决于是否命中索引。没走索引、或走了索引但查询条件是 LIKE '%abc' 这类无法使用索引下推的场景，优化器可能放弃使用索引，导致全表扫描——此时 InnoDB 会对所有扫描过的记录加锁，甚至退化为间隙锁+临键锁组合，看起来就像“锁了整张表”。
常见诱因包括：
- WHERE 条件字段未建索引，或索引失效（如对索引列做函数操作：
WHERE YEAR(create_time) = 2023） - 使用
OR连接多个非组合索引字段，且无法走索引合并 - 事务中执行
SELECT ... FOR UPDATE时，扫描范围过大（例如没加 LIMIT，也没用主键/唯一索引定位）
间隙锁（Gap Lock）和临键锁（Next-Key Lock）的实际影响
InnoDB 在可重复读（REPEATABLE READ）隔离级别下，默认使用临键锁（即间隙锁 + 记录锁），目的是防止幻读。但这会显著扩大锁范围，尤其在范围查询（如 SELECT * FROM t WHERE id BETWEEN 10 AND 20 FOR UPDATE）时，不仅锁住已存在的 10–20 行，还会锁住 (5,10)、(20,25) 这类间隙，阻止其他事务插入 id=7 或 id=22 的新行。
关键事实：
- 唯一等值查询（含主键、唯一索引 + 精确匹配）只加记录锁，不加间隙锁
- 非唯一索引的等值查询，仍会加临键锁（比如
name = 'Alice'，即使 name 有索引但不唯一） -
INSERT操作本身会先检查插入位置是否被间隙锁阻挡，若被锁则等待，这是死锁高发点
如何安全地减少锁冲突与死锁概率
死锁不是 bug，而是并发事务竞争资源的自然结果。InnoDB 能检测并回滚其中一个事务，但高频死锁会影响业务稳定性。核心思路是统一访问顺序、缩短事务时间、避免锁升级。
