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 能检测并回滚其中一个事务，但高频死锁会影响业务稳定性。核心思路是统一访问顺序、缩短事务时间、避免锁升级。
实操建议：
所有涉及多行更新的逻辑，按主键（或同一索引）升序排列后再处理，例如先ORDER BY id ASC再
FOR UPDATE把
SELECT ... FOR UPDATE尽量靠近事务末尾，避免长时间持锁；不要在事务里混杂网络调用或用户输入等待 确认业务是否真的需要
REPEATABLE READ：如果允许幻读，可降级到
READ COMMITTED，此时间隙锁被禁用（仅保留记录锁），大幅降低锁范围 监控死锁日志：
SHOW ENGINE INNODB STATUS\G中的
LATEST DETECTED DEADLOCK段落，重点关注
TRANSACTION的 SQL 和
WAITING FOR THIS LOCK TO BE GRANTED行
唯一索引冲突时的锁行为容易被忽略
当插入违反唯一约束（如重复主键或唯一索引值）时，InnoDB 不仅会报错，还会在冲突值对应的索引记录上加一个“插入意向锁”（Insert Intention Lock），这是一种特殊的间隙锁。它和其他事务的间隙锁兼容，但和记录锁互斥——这解释了为什么两个事务同时
INSERT同一主键会直接报错，而同时
INSERT相邻值（如 100 和 101）却可能因间隙锁等待形成死锁。
典型陷阱：
用INSERT IGNORE或
ON DUPLICATE KEY UPDATE处理重复插入时，仍会触发唯一索引检查并加锁，不能认为“忽略就等于不锁” 批量插入（
INSERT ... VALUES (...), (...)）中某一行失败，不影响其余行提交，但整个语句的锁行为仍按实际插入路径计算，不可假设原子性
INSERT INTO users (id, name) VALUES (1, 'A'), (2, 'B'), (1, 'C') -- 第三个值因主键冲突失败，但 id=1 的记录已被加锁，后续事务想查或更新 id=1 会被阻塞
锁机制不是越细越好，也不是越少越好。真正影响性能的，往往是那些本可避免的隐式锁升级、未意识到的间隙范围，以及事务中混入的非数据库操作。查
information_schema.INNODB_TRX和慢日志里的
Lock_wait时间，比背理论更能定位问题。
