【原理篇】2.聊聊MySQL的存储引擎-磁盘结构-冰点博客

通过官网的下图，我们可以清晰的看到，整个innodb的架构官方分为了内存结构和磁盘结构。
上章节我们讨论了左侧的 in-memory structures 本章节，我们讨论右侧的磁盘结构或叫文件结构

方便大家理解，我梳理了一个完整的流程图，供大家参考

1.1 表空间体系：数据存储的“容器”

系统表空间以 ibdata1 等文件为物理载体（默认单文件，可通过配置拆分），承担着多重关键职责：

元数据存储：记录 InnoDB 整个实例的元数据，如表结构定义、列信息、索引元数据等，是数据库“字典”的核心存储区。
Change Buffer 承载：内置 Change Buffer ，用于缓存对非唯一二级索引页的修改（如插入、更新操作）。这些修改先在内存中暂存，后续通过后台线程或其他触发机制，合并到实际数据页，减少随机磁盘写，提升写性能。
历史数据兜底：当未启用独立表空间（innodb_file_per_table=OFF ）时，所有表的数据、索引也会存储于此。不过，这种模式易导致 ibdata1 膨胀且难以收缩，现代实践中多推荐启用独立表空间。

当 innodb_file_per_table=ON（默认开启）时，每个 InnoDB 表会生成独立的 .ibd 文件（如 t1.ibd、t2.ibd ），特点鲜明：

隔离性强：表的数据、索引、自适应哈希索引（Adaptive Hash Index ）相关结构独立存储，某张表的操作（如磁盘空间回收、表迁移）不影响其他表。
空间管理灵活：支持通过 ALTER TABLE ... ENGINE=InnoDB 在线收缩空间（实际是重建表），或使用 OPTIMIZE TABLE 整理碎片，优化存储效率。

通用表空间是一种灵活的自定义表空间形式，通过 CREATE TABLESPACE 语句创建，可存储多个表的数据。例如图中的 ts1.ibd ，可包含 t3、t4 等多张表。其优势在于：

分为全局临时表空间（ibtmp1 ）和会话级临时表空间（temp_1.ibt 等）：

全局临时表空间：存储用户创建的临时表（CREATE TEMPORARY TABLE ）、内部临时表（如复杂查询排序/分组时生成的中间表）的元数据及数据。
会话级临时表空间：每个会话按需创建，存储会话专属的临时数据，会话结束后自动清理，避免全局资源竞争，保障多会话并发时的稳定性。

以 ib_16384_0.dblwr、ib_16384_1.dblwr 为代表，是 InnoDB 防止部分写失败（Partial Write Failure ）的关键设计：

工作原理：当缓冲池（Buffer Pool ）的脏页需要刷盘时，先将数据写入双写缓冲区文件（顺序写，效率高），再从双写缓冲区刷到实际数据页。若磁盘写过程中发生故障（如掉电、磁盘坏道），重启时 InnoDB 可从双写缓冲区恢复完整数据页，避免因数据页损坏导致实例崩溃或数据丢失。
性能平衡：虽然增加了一次写操作，但通过顺序写优化和异步刷盘机制，对性能影响可控，却极大提升了数据可靠性，是金融、交易等核心业务的“必选防护”。

重做日志以 #ib_redo_N、#ib_redo_N_tmp 文件形式存在，是实现事务持久性（Durability ）的基石：

事务持久化流程：事务修改数据时，先将变更记录写入日志缓冲区（Log Buffer ），提交时（或按 innodb_flush_log_at_trx_commit 策略）刷盘到重做日志。即使数据库崩溃，重启后 InnoDB 可通过重做日志“重演”未持久化到数据页的变更，保障事务完整性。
文件特性：采用循环写模式，多个日志文件交替使用，避免文件无限膨胀。通过 innodb_log_file_size 可调整单文件大小，innodb_log_files_in_group 设置文件数量，需结合业务写负载（如大事务场景需增大日志文件）优化。

包含系统回滚表空间（undo_001、undo_002 ）和用户定义回滚表空间（undo_003.ibu 等），支撑事务回滚与多版本并发控制（MVCC ）：

事务回滚：当事务执行 ROLLBACK ，或因错误需回退时，InnoDB 从回滚表空间读取旧版本数据，恢复到事务开始前状态。
MVCC 实现：查询时，若需读取历史版本（如可重复读隔离级别下），通过回滚表空间中记录的 undo 日志，构建符合隔离级别的数据视图，实现读写不阻塞，提升并发性能。
空间管理：独立回滚表空间可通过 innodb_undo_tablespaces 配置数量，支持自动 truncate （innodb_undo_log_truncate=ON ），避免回滚日志无限占用磁盘空间。

InnoDB 磁盘结构并非孤立存在，与内存结构（Buffer Pool、Change Buffer、Log Buffer 等）紧密协同：

写流程：用户事务修改数据时，先更新 Buffer Pool 中的数据页（标记为脏页），非唯一索引修改缓存到 Change Buffer ；同时，事务日志写入 Log Buffer ，并按策略刷盘到 Redo Log 。后台线程（如 Master Thread ）定期将 Change Buffer 合并到数据页，脏页按 LRU 策略或触发条件刷盘到磁盘表空间。
读流程：查询时优先访问 Buffer Pool ，未命中则从磁盘表空间加载数据页到内存；若数据页存在历史版本，通过 Undo Tablespaces 中的日志构建 MVCC 视图，保障读一致性。