MySQL锁机制核心在于理解锁的触发场景与规避死锁：行锁需走索引，否则升级为表锁；RR级别用gap/next-key锁防幻读，RC仅用record锁；死锁通过wait-for graph检测，优化需确保索引、缩短事务、按序更新。
MySQL 锁机制是面试高频考点，重点不在死记类型名称，而在于理解“为什么需要这个锁”“在什么场景下会被触发”“如何避免冲突和死锁”。掌握锁的粒度、加锁时机、事务隔离级别与锁的关系，才能应对实际问题。
行锁 vs 表锁：核心区别与触发条件
InnoDB 默认使用行级锁（实际是索引记录锁），但前提是 SQL 走了索引。如果查询条件没命中索引（比如全表扫描或用到非索引字段），InnoDB 会升级为表锁（更准确说是对所有扫描过的索引记录加锁，效果接近表锁）。
- 主键/唯一索引等值查询 → 只锁匹配的单行（record lock）
- 普通索引等值查询 → 锁该索引记录 + 对应的主键记录（可能涉及 gap lock）
- 范围查询（如
WHERE age > 20）→ 加临键锁（next-key lock = record lock + gap lock），既锁记录也锁间隙 -
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE显式加锁，即使无 WHERE 条件也会锁全表（若没索引）
间隙锁（Gap Lock）和临键锁（Next-Key Lock）：防幻读的关键
间隙锁不是锁记录，而是锁两个索引值之间的“空隙”，防止其他事务在这个间隙插入新记录。它只在 可重复读（RR） 隔离级别下生效，且仅对普通索引或范围查询起作用。
- 主键等值查询不会加 gap lock（只加 record lock）
- 唯一索引等值查询，若记录存在则只加 record lock；若记录不存在，则加 gap lock（用于防止插入）
- RR 下
UPDATE t SET name='x' WHERE age=30，若 age 是普通索引，会加 next-key lock，覆盖 age=30 所在的整个索引区间 - 读已提交（RC）级别下，InnoDB 不使用 gap lock 和 next-key lock，只加 record lock，因此可能产生幻读
锁兼容性与死锁：如何看懂死锁日志
MySQL 通过 wait-for graph 检测死锁，自动回滚代价小的事务。关键要能从 SHOW ENGINE INNODB STATUS 中提取信息：
- 找到
*** (1) TRANSACTION:和*** (2) TRANSACTION:分别是谁 - 看各自持有的锁（
HOLDS THE LOCK(S):）和等待的锁（WAITING FOR THIS LOCK TO BE GRANTED:） - 确认是否形成循环等待（如事务 A 持有 X 锁等待 Y，事务 B 持有 Y 锁等待 X）
- 常见诱因：多表更新顺序不一致、非唯一索引范围更新、长事务持有锁太久
实战建议：减少锁冲突的常用手段
锁本身不可怕，可怕的是锁住不该锁的、锁太久、或者锁顺序混乱。优化方向很明确：
- 确保 WHERE 条件走索引（explain 看 type 是否为 const/ref/range）
- 尽量缩短事务长度，避免在事务中做耗时操作（如远程调用、大循环）
- 批量更新时按主键顺序执行（避免行锁顺序不一致引发死锁）
- 高并发写场景，考虑用乐观锁（version 字段）替代悲观锁
- 必要时降级隔离级别（如 RC），但需评估业务能否接受幻读
