MySQL锁机制相关问题
针对MySQL锁机制相关问题，我准备了一个“一句话原理 + 一句话源码 + 一句话项目/场景”的结构化回答，体现深度同时展现实战能力。
锁的分类
MySQL 中有哪些锁类型？（全局锁、表锁、行锁、间隙锁、Next-Key Lock）
原理层面： MySQL 锁机制按粒度从大到小分为全局锁、表级锁（含元数据锁 MDL、意向锁）和行级锁（含 Record Lock、Gap Lock、Next-Key Lock），旨在通过不同粒度的互斥控制，在保证数据一致性与并发性能之间寻求最佳平衡。
源码层面：
在 InnoDB 源码架构中，全局锁与表锁由 SQL 层的锁管理器实现，而行级锁结构（lock_t）存储在事务对象的 lock_heap 中，通过锁对象的 type_mode 属性区分 LOCK_REC（行锁）或 LOCK_GAP（间隙锁）等具体类型。
项目/场景层面： 在电商大促等高并发业务场景中，应尽量避免全局锁（FTWRL）导致的全库只读阻塞，并利用 InnoDB 在 RR 级别下的 Next-Key Lock 机制解决超卖等幻读问题，同时需严防无索引行锁升级为表锁引发的系统性能雪崩。
InnoDB 的行锁是如何实现的？
原理层面： InnoDB 行锁通过给索引上的索引项加锁来实现，这意味着只有通过索引条件检索数据时才能使用行锁，否则会退化为表锁。
源码层面：
在内核实现中，行锁对象被挂载在全局哈希表中，以 (Space ID, Page No) 为 Key 查找，并通过位图结构精确锁定 Page 内具体的物理记录偏移量。
项目/场景层面： 在业务开发中若 Update 操作未命中索引，会导致锁升级为表锁，在高并发下极易引发数据库连接池耗尽与服务不可用，因此生产环境必须对 SQL 执行计划进行严格审查。
共享锁和排他锁的区别？如何手动加锁？（SELECT … LOCK IN SHARE MODE / FOR UPDATE）
原理层面： 共享锁（S锁）允许事务读取数据并阻止其他事务对其进行修改，支持多事务并发读；排他锁（X锁）允许事务更新数据并阻止其他事务进行任何读写操作，独占资源。
源码层面：
InnoDB 通过锁结构中的 type_mode 属性区分锁类型，S 锁与 S 锁兼容，但 X 锁与 S 锁、X 锁均互斥，加锁时需遍历锁兼容矩阵检查是否存在冲突的事务 ID。
项目/场景层面：
在扣减库存场景中使用 SELECT ... FOR UPDATE（加排他锁）可以防止超卖；而在上游数据分发核对场景中，使用 SELECT ... LOCK IN SHARE MODE（加共享锁）可确保读取数据的一致性快照，同时允许其他核对任务并发读取，提升效率。
什么是意向锁？它的作用是什么？
原理层面： 意向锁是一种表级锁，用于表明事务即将在表中的某些行上加锁（S锁或X锁），其核心作用是协调行锁与表锁的并发，避免事务在申请表锁时逐行检查行锁状态，极大提升锁冲突检测效率。
源码层面：
InnoDB 在为行记录加锁前，会先在对内存中的表对象（dict_table_t）加意向锁（IS 或 IX），其锁兼容矩阵规定意向锁之间兼容，但 IX/IS 与表级的 X/S 锁互斥，从而在表级层面快速阻断冲突。
项目/场景层面： 在海量并发的 OLTP 系统中，意向锁避免了“事务 A 锁了一行，事务 B 想锁全表时需扫描全表行锁”的性能灾难，实现了行锁与表锁的高效共存，保障了数据库在高并发下的吞吐能力。
锁的应用
什么是间隙锁（Gap Lock）？它解决了什么问题？
原理层面： 间隙锁是 InnoDB 在可重复读（RR）隔离级别下引入的机制，用于锁定索引记录之间的“间隙”，严格阻止其他事务在该范围内插入新记录，从而彻底解决幻读问题。
源码层面：
在锁结构 lock_t 中，通过 type_mode 字段标记为 LOCK_GAP，其仅与插入意向锁冲突，与普通的记录锁或间隙锁本身兼容，且锁定范围依据索引扫描路径动态计算。
项目/场景层面：
在金融账户流水号管理或库存防超卖场景中，执行 SELECT * FROM table WHERE id > 100 FOR UPDATE 会锁定 (100, +∞) 的间隙，有效防止恶意事务插入“幽灵记录”导致数据校验通过但实际数据被篡改的安全隐患。
死锁是如何产生的？如何排查和避免死锁？
原理层面： 死锁是指两个或多个事务在执行过程中，因争夺资源而形成的一种互相等待的环形阻塞现象，若无外力干涉，所有事务都将无法推进。
源码层面：
在 InnoDB 源码架构中，锁管理器（lock_sys）维护着全局锁哈希表与等待图，内部死锁检测线程会定期扫描该图，一旦发现闭合环路，即刻触发回滚机制，选择代价最小的事务进行牺牲。
项目/场景层面： 在订单与库存扣减的分布式事务中，若线程 A 先锁订单后锁库存，而线程 B 先锁库存后锁订单，极易瞬间引发死锁导致业务报错；生产环境必须通过统一资源获取顺序（如总是先操作主表后操作从表）来从架构层面根除此隐患。
你在项目中遇到过死锁吗？怎么解决的？
原理层面： 死锁通常源于“资源申请顺序不一致”，即并发事务交叉持有对方所需的资源，从而形成闭环等待。
源码层面：
通过分析 Lock Graph（锁等待图），定位到多个事务持有的 lock_t 结构形成有向环，InnoDB 检测线程随即触发回滚机制，回滚权重最小的事务以打破死链。
项目/场景层面： 曾遇“批量更新物流状态”死锁，根源是程序按“用户输入顺序”逐行加锁，导致不同事务对同一组记录加锁顺序相反；最终通过在业务层对待更新的主键 ID 列表进行强制排序，将随机抢占转化为有序申请，彻底解决了死锁问题。
如何查看当前 MySQL 的锁等待情况？（SHOW PROCESSLIST、INFORMATION_SCHEMA 相关表）
原理层面：
MySQL 通过内存中的锁管理器维护事务间的等待关系，查看锁等待本质就是检索持有者与等待者的映射状态，核心手段包括传统的 PROCESSLIST 状态位、INFORMATION_SCHEMA 的锁视图以及 MySQL 5.7+ 引入的 sys 库便捷视图。
源码层面：
INFORMATION_SCHEMA.INNODB_LOCK_WAITS 等视图底层直接映射了 InnoDB 内核 lock_sys 结构中的 lock_heap 和事务链表，将内存中的 lock_t 二进制结构实时解析为可读的行锁与事务 ID 信息。
项目/场景层面：
生产环境出现 Lock wait timeout exceeded 报警时，通过 SELECT * FROM sys.innodb_lock_waits 快速定位阻塞源头的线程 ID（blocking_pid），配合 SHOW PROCESSLIST 查明具体 SQL，进而实施 KILL 或业务优化，实现分钟级故障恢复。
乐观锁和悲观锁在 MySQL 中如何实现？各自适用场景？
原理层面： 悲观锁利用数据库内置的锁机制在读取时显式加锁，强行串行化操作；乐观锁不加锁，而是在提交更新时通过版本号比对来检测冲突，本质是基于 CAS 思想的“提交检验”。
源码层面：
悲观锁依赖 SELECT ... FOR UPDATE 调用 lock_rec_add_to_queue 加载排他锁记录；乐观锁依赖 UPDATE table SET version = new WHERE id = x AND version = old，通过 InnoDB 的版本链与事务可见性判断更新影响的行数是否为 1。
项目/场景层面：
在抢购秒杀的高并发写场景，使用悲观锁 FOR UPDATE 防止超卖；在博客文章编辑或后台信息修改等读多写少场景，使用乐观锁版本号机制，既避免了长事务锁阻塞，又解决了并发覆盖问题。