【MySQL InnoDB 内核】InnoDB 存储引擎机制深度拆解
内容提要
本文为InnoDB存储引擎内核系列文章，共20章，系统讲解其架构、MVCC、锁机制、崩溃恢复、复制等核心机制，并与PostgreSQL进行对比。文章提供阅读路径、目录及故障排查方法，旨在帮助工程师深入理解MySQL与PostgreSQL的设计差异。
延伸解读
阅读路径设计：按角色快速定位
系列提供六条阅读路径，分别面向DBA、从PG转MySQL的工程师、内核开发者、高可用运维、应急处理和查询优化场景。例如，DBA日常排查建议从架构、Buffer Pool、MVCC、锁、监控和故障模式入手，而内核开发者则需按存储与恢复顺序精读。这种设计帮助读者根据自身角色和需求，避免盲目通读，提高学习效率。
PG对照：建立差异直觉的关键
每章末尾设「PG对照」小节，引用PostgreSQL内核系列对应篇章，直接对比InnoDB与PG在MVCC、锁、WAL等核心机制上的设计分叉。例如，InnoDB用undo log实现多版本，而PG用CLOG和hint bit；InnoDB的gap lock与PG的行锁模型不同。这种对照有助于已熟悉PG的工程师快速理解MySQL的独特设计，减少认知转换成本。
源码锚定与版本差异标注
系列以MySQL 8.0 LTS（源码tag mysql-8.0.36）为锚定，并在文中标注5.7关键差异。这意味着读者可以对照具体源码文件（如srv0srv.cc、buf0buf.cc）深入理解机制，同时注意版本差异，避免将8.0特性误用于5.7环境。对于生产环境版本管理有实际指导意义。
Q&A
InnoDB 存储引擎的线程模型和内存布局是怎样的？
InnoDB 的线程模型包括 Master thread、purge thread、read/write IO thread 和 page cleaner，各自负责不同的后台任务。内存布局主要包括 Buffer Pool、Log Buffer、Change Buffer 和 AHI（自适应哈希索引）。Buffer Pool 被划分为多个 chunk 和 instance 以提升并发性能。
InnoDB 的 MVCC 为什么使用 undo log 而不是像 PostgreSQL 那样的多版本行？
InnoDB 使用 undo log 实现 MVCC，通过在聚簇索引记录上保存 DB_TRX_ID 和 DB_ROLL_PTR 隐藏列，结合 Read View 和 undo 链来构建可见版本。而 PostgreSQL 使用 CLOG 和堆表上的多版本行（通过 xmin/xmax 标记）。两种方案在设计上有明显差异，InnoDB 的 undo log 方案在事务回滚和版本清理方面有不同机制。
InnoDB 的锁机制具体锁的是什么？与 PostgreSQL 的行锁有何不同？
InnoDB 的锁包括记录锁、间隙锁、Next-Key Lock、意向锁和 MDL。记录锁锁的是索引记录，间隙锁锁的是索引记录之间的间隙，Next-Key Lock 是记录锁和间隙锁的组合。而 PostgreSQL 主要使用行锁（基于元组），没有间隙锁的概念，但通过可序列化快照隔离（SSI）处理幻读。
InnoDB 崩溃恢复时 redo 和 undo 各起什么作用？
崩溃恢复时，InnoDB 首先通过 redo log 重放（redo apply）将已提交但未写入数据文件的更改恢复，然后通过 undo log 回滚（undo rollback）未提交的事务。整个过程分为两个阶段，从 checkpoint 开始，使用 LSN 和 Mini-Transaction 确保一致性。
binlog 和 InnoDB redo log 是如何协调的？
binlog 和 InnoDB redo log 通过两阶段提交（2PC）协议协调，涉及 XID 和组提交（group commit）。InnoDB 的 redo log 记录事务的物理更改，binlog 记录逻辑更改，两者通过 XID 关联，确保崩溃恢复时的一致性。组提交可以提升性能，但可能影响主从延迟。
InnoDB 最危险的故障模式有哪些？
InnoDB 最危险的故障模式包括：长事务导致 undo 膨胀、脏页 flush 跟不上（flush 列表堆积）、gap lock 死锁、半同步复制降级等。这些故障可能引发性能下降、磁盘空间耗尽或数据不一致。
InnoDB 的 Change Buffer 和自适应哈希索引（AHI）的作用是什么？
Change Buffer 用于延迟二级索引的写操作，将非唯一二级索引的修改缓存起来，在合适的时机合并，以减少随机 I/O。AHI 是自适应哈希索引，用于加速索引查找，但在 MySQL 8.0 中默认关闭，因为其维护成本高且收益有限。
如何排查 InnoDB 的性能问题？
排查 InnoDB 性能问题可以采用分层调查法：先使用 EXPLAIN ANALYZE 分析查询计划，再通过 Performance Schema 查看等待事件，然后检查 SHOW ENGINE INNODB STATUS 的输出，最后使用 iostat/perf 等系统工具分析 I/O 和 CPU 瓶颈。
