锁管理器

本文拆解 InnoDB 锁管理器 的核心机制，源码锚定 MySQL 8.0.36 storage/innobase/。 先说明生产场景中的典型误区，再给出源码路径、流程图、实验步骤（需本地验证）与 PG 对照。

一、问题与场景

锁管理器 直接影响 DML 延迟、崩溃恢复窗口与并发语义。排查时应避免只调单个全局变量而不理解 其背后的列表结构、线程职责与 LSN 语义。

二、核心数据结构

InnoDB 在 锁管理器 路径上使用专用结构与 latch。阅读代码时先定位 include/ 头文件中的结构体， 再读 .cc 实现。所有路径相对于 storage/innobase/。

flowchart LR
  A[连接线程 THD] --> B[锁管理器]
  B --> C[Buffer Pool]
  B --> D[Redo Log]
  B --> E[Undo Log]

三、关键算法与状态机

状态转换必须在 mtr 内完成以保证 redo 一致。页级 latch 与全局 mutex 分层使用—— 长临界区会放大 threads_waiting 与 mutex_spin_wait 指标。

stateDiagram-v2
  [*] --> Active
  Active --> Persisted: commit 路径
  Active --> Aborted: rollback
  Persisted --> [*]
  Aborted --> [*]

四、源码阅读路径

1. 从本章 PLAN.md 列出的焦点文件入手
2. 用 grep -r 在 mysql-8.0.36/storage/innobase 搜索结构体名（本地 clone 源码）
3. 对照 UNIV_DEBUG 断言理解不变量

五、与 checkpoint / LSN 的关系

锁管理器 与 log_sys->lsn、buf_pool->flush_list 存在耦合。flush 列表过长会阻碍 redo 回收； undo history 过长会拖慢 purge 与一致性读性能——监控 SHOW ENGINE INNODB STATUS 的 TRANSACTIONS 段与 LOG 段。

六、实验（需本地验证）

SHOW ENGINE INNODB STATUS\G
SHOW VARIABLES LIKE 'innodb_%';

SELECT NAME, COUNT FROM information_schema.INNODB_METRICS
WHERE NAME LIKE '%锁管理器%' OR NAME LIKE 'buffer%';

本仓库写作环境未安装 MySQL——不得粘贴未实测的输出。请在 Docker 官方 mysql:8.0.36 镜像验证，记录版本与参数快照。

七、工程坑点

• 5.7 与 8.0 线程模型差异未标注就套用旧文档
• 把 SQL 事务与 mtr 混为一谈
• 单实例压测结论推广到多实例生产
• 忽略 innodb_page_size 对页内结构的影响

八、PG 对照

详见 PG 对应章节。PG 用多版本堆行 + WAL；InnoDB 用 undo 链 + redo + gap lock（部分场景）。对照学习时关注「同一隔离语义的不同实现」，而非强行对齐语法。

九、边界

• 社区版 MySQL 8.0.36；不覆盖 Aurora/RDS 内部实现
• 不展开 MySQL Server 优化器全文
• MariaDB fork 以 Release Notes 为准

上一篇：隔离级别

下一篇：崩溃恢复

参考资料

1. MySQL 8.0 Source, storage/innobase/, tag mysql-8.0.36
2. MySQL 8.0 Reference Manual, InnoDB
3. 本站 PG 内核系列