MySQL 5.7 系列：集中式架构下的“局部突围”（2014–2023）
MySQL 5.7 虽然整体上仍是“一切以 ibdata1 为中心”，但在其 40 余个版本中，InnoDB 团队进行了多项前瞻性的模块化尝试，为后续彻底重构埋下伏笔。
3.1 关键版本演进
| 版本 | 日期 | InnoDB 里程碑 | 意义 |
|---|---|---|---|
| 5.7.4 | 2014-03-31 | 共享临时表空间首次从 ibdata1 独立（ibtmp1） | 第一个从“大仓库”中剥离的模块 |
| 5.7.5 | 2014-09-25 | 引入innodb_buffer_pool_dump_pct | Buffer Pool 预热粒度精细化 |
| 5.7.6 | 2015-03-10 | 支持 32KB/64KB 页大小；Online DDL 重构 | 为大型页和在线变更奠定基础 |
| 5.7.8 | 2015-08-03 | 只读事务优化，跳过部分事务对象开销 | 纯查询场景吞吐量提升 |
| 5.7.11 | 2016-02-05 | 引入innodb_tmpdir，Online DDL 临时目录可独立指定 | 避免 DDL 填满系统 tmpdir |
| 5.7.14 | 2016-07-29 | innodb_io_capacity精细化控制，默认 max 提升至 200000 | 更好地适配 SSD |
| 5.7.18 | 2017-04-10 | InnoDB 表空间加密正式 GA | 满足合规要求 |
| 5.7.21 | 2018-01-15 | 并行读取能力初步优化 | 为后续并行 DDL 预热 |
| 5.7.22 | 2018-04-19 | Change Buffer 合并触发机制改进 | 减少 I/O 峰值 |
| 5.7.23 | 2018-07-27 | 临时表空间最大尺寸可控 | 防止 ibtmp1 无限膨胀 |
| 5.7.44 | 2023-10-25 | 5.7 最终版，10 月 31 日 EOL | 五年扩展支持结束 |
3.2 重要演进解读
临时表空间独立（5.7.4）
这是 InnoDB 第一次将一类核心数据从 ibdata1 中移出。内部临时表和显式临时表存储于独立的 ibtmp1 文件，可单独配置大小和位置，避免临时数据污染系统表空间。
Buffer Pool 预热精细化（5.7.5）
在 5.6 时代，Buffer Pool 转储/加载只有全量模式。5.7.5 引入innodb_buffer_pool_dump_pct（默认 25），允许仅转储最热的一部分页面，大大缩短实例重启后的预热时间。
I/O 能力控制增强（5.7.14）innodb_io_capacity默认值从 200 提升到 2000？实际 5.7 早期默认 200，5.7.14 后更强调参数的控制效果。innodb_io_capacity_max默认值直接提升至 200000，匹配当代 SSD 的爆发放置能力。
表空间加密（5.7.18）
支持对独立表空间（.ibd）进行透明数据加密，采用 Keyring 插件管理密钥。这使得 MySQL 能够满足 PCI-DSS、GDPR 等合规要求。
Change Buffer 调度改进（5.7.22）
5.7.22 对 Change Buffer 的合并策略做了重要修正：减少因合并操作导致的 I/O 突发，使 I/O 负载更加平滑。
临时表空间可控（5.7.23）
通过innodb_temp_data_file_path可设置最大尺寸（如ibtmp1:12M:autoextend:max:10G），防止失控查询撑爆磁盘。
3.3 5.7 时代的遗留痛点
尽管 5.7 做出了诸多局部优化，其根本性缺陷依然存在：
- 数据字典、Undo、Doublewrite 仍挤在 ibdata1，空间只增不缩；
- DDL 非原子性：中途失败可能留下孤表或损坏的字典；
- 无独立 General Tablespaces：用户只能在“每个表一个 .ibd”和“全部塞进 ibdata1”之间二选一。
解决这些问题，必须依靠下一代的架构重构——MySQL 8.0。
四、MySQL 8.0 系列：十年架构重构的主战场（2016–2026）
MySQL 8.0 从 2016 年 9 月首个开发里程碑到 2026 年 5 月 EOL，历时近十年，发布了超过 40 个小版本。它完成了 InnoDB 历史上最彻底的一次底层重塑——从数据字典到 Undo、从 Redo Log 到 Doublewrite，几乎每一个磁盘组件都被重新设计。
4.1 开发里程碑与候选版（8.0.0 – 8.0.4）
| 版本 | 日期 | 重大变革 |
|---|---|---|
| 8.0.0 | 2016-09-12 | 事务数据字典（mysql.ibd）首次引入，原子 DDL 奠基 |
| 8.0.1 | 2017-04-10 | 自增主键持久化 |
| 8.0.2 | 2017-07-27 | Undo 表空间默认独立（innodb_undo_tablespaces=2） |
| 8.0.3 | 2017-09-21 | Redo Log 无锁写入，多线程并发写 Log Buffer |
| 8.0.4 | 2018-01-23 | 默认内存临时表从 MEMORY 引擎变更为 TempTable 引擎 |
解读：
- 事务数据字典（8.0.0）：所有元数据（表、列、索引等）从
.frm文件移入 InnoDB 的系统表中，DDL 变为原子操作，不再有“部分成功”状态。这是 8.0 最基础的重构。 - Undo 独立（8.0.2）：虽然 5.7 已经支持独立 Undo 表空间，但默认仍为 0。8.0.2 将默认值改为 2，即安装后自动创建两个 Undo 表空间（
undo_001、undo_002），Undo 从此彻底脱离 ibdata1。 - Redo Log 无锁写入（8.0.3）：传统 Redo Log 写入需要竞争全局 mutex，高并发下成为瓶颈。8.0.3 允许多个用户线程同时写入 Log Buffer，极大提升了事务日志吞吐量。
- TempTable 引擎（8.0.4）：新的内存临时表引擎支持变长字段（VARCHAR/VARBINARY），优于 MEMORY 引擎的固定长度存储，减少内存浪费和磁盘落盘。
4.2 正式 GA：MySQL 8.0.11（2018-04-19）
8.0.11 是 MySQL 8.0 的首个General Availability（GA）版本，标志着上述所有重构已可安全用于生产。自此，8.0 系列进入长期支持阶段，同时继续添加新特性。
4.3 功能丰富与性能优化（8.0.12 – 8.0.19）
| 版本 | 日期 | 关键特性 |
|---|---|---|
| 8.0.13 | 2018-10-22 | TempTable 引擎支持 BLOB；双写缓冲区参数精细化 |
| 8.0.14 | 2019-01-21 | SQL 级动态管理 Undo 表空间（CREATE UNDO TABLESPACE） |
| 8.0.15 | 2019-02-01 | 死锁检测可在线关闭（innodb_deadlock_detect） |
| 8.0.16 | 2019-04-25 | 系统表空间（mysql.ibd）加密；innodb_dedicated_server自动适配内存 |
| 8.0.17 | 2019-07-22 | 多线程 Page Cleaner 调度优化 |
| 8.0.19 | 2020-01-13 | InnoDB ReplicaSet 正式 GA |
解读：
- 动态 Undo 管理（8.0.14）：DBA 可以随时
CREATE UNDO TABLESPACE添加新的 Undo 表空间，或ALTER UNDO TABLESPACE ... SET INACTIVE再DROP，配合在线截断功能，彻底解决了 Undo 空间回收难题。 - 死锁检测可控（8.0.15）：在高并发系统中，死锁检测本身可能消耗大量 CPU。设置
innodb_deadlock_detect=OFF后，依赖innodb_lock_wait_timeout超时机制，可提升吞吐量。 - 系统表空间加密（8.0.16）：此前只能加密用户表空间，现在连数据字典所在的
mysql.ibd也可加密，实现了全实例加密。
4.4 核心组件独立高峰（8.0.20 – 8.0.27）
| 版本 | 日期 | 里程碑事件 |
|---|---|---|
| 8.0.20 | 2020-04-27 | Doublewrite Buffer 从 ibdata1 独立到#ib_16384_0.dblwr文件 |
| 8.0.22 | 2020-10-19 | Instant DDL 支持ADD COLUMN |
| 8.0.23 | 2021-01-18 | 全文本索引性能优化 |
| 8.0.27 | 2021-10-19 | 并行 DDL（innodb_ddl_threads=4） |
解读：
- Doublewrite 独立（8.0.20）：这是极其关键的一步。双写缓冲区长久以来固定在 ibdata1 开头，与系统表空间耦合。8.0.20 将其迁出，成为独立的双写文件（每个 Buffer Pool 实例对应两个文件）。这降低了写延迟，也为后续使用 Atomic I/O 彻底替代 Doublewrite 铺平了道路。
- Instant DDL ADD COLUMN（8.0.22）：当在表末尾添加列时，不再需要重建表和数据，只需修改数据字典中的表定义。对于超大表（TB 级），此操作从小时级降至毫秒级。
- 并行 DDL（8.0.27）：创建或重建二级索引时，可使用多个线程并行排序和构建。这是 DDL 性能的里程碑——索引创建时间与 CPU 核心数近似成反比，极大缩短了大表维护窗口。
4.5 后期收敛与维护（8.0.30 – 8.0.41）
| 版本 | 日期 | 变化 |
|---|---|---|
| 8.0.30 | 2022-07-26 | Redo Log 容量管理简化（innodb_redo_log_capacity） |
| 8.0.32 | 2023-01-17 | Instant DDL 支持DROP COLUMN |
| 8.0.36 | 2024-01-16 | 锁系统性能稳定性加强 |
| 8.0.41 | 2025-01-21 | 8.0 系列后期版本，安全修复为主 |
解读：
- Redo Log 简化（8.0.30）：过去需要同时配置
innodb_log_file_size和innodb_log_files_in_group，易出错。8.0.30 引入innodb_redo_log_capacity（默认 100M），自动管理文件数量和大小。 - Instant DROP COLUMN（8.0.32）：扩展 Instant DDL 能力，删除列也可瞬间完成。
- 生命周期终点：MySQL 8.0 于2026 年 5 月 1 日正式结束扩展支持，所有用户被强烈建议升级至 8.4 LTS 或 9.7 LTS。
五、MySQL 8.4 LTS：双轨制下的“稳定基座”（2024）
2024 年 4 月 30 日，Oracle 发布了MySQL 8.4.0 LTS，这是新双轨制（LTS + Innovation）下的第一个长期支持版本。
8.4 LTS 并未引入大量新特性，其核心任务是：
- 稳定化8.0 系列的所有架构成果（事务数据字典、独立 Undo、原子 DDL、并行 DDL 等）；
- 调整默认值以适配现代硬件和最佳实践，例如：
innodb_change_buffering默认值从all改为none（NVMe SSD 下合并收益变小）；mysql_native_password默认禁用；- Buffer Pool 实例数量自动随 CPU 核数调整。
- 为 Innovation 版本铺路：8.4 作为长期支持版本的基准，使得后续 9.0+ 创新版可以更大胆地试验新功能。
对于大多数生产环境，8.4 LTS 是比 8.0 更可靠的升级目标，也是最终走向 9.7 LTS 的必要跳板。
六、MySQL 9.x Innovation 系列：为 LTS 做实战打磨（2024–2026）
从 2024 年 7 月开始，MySQL 进入 Innovation 快速迭代期。9.0、9.1、9.2 …… 9.6 每季度发布一个新版本，每个版本都包含若干 InnoDB 层面的优化。这些优化在 9.7 LTS 中被统一集成。
6.1 创新版关键 InnoDB 改进汇总
| 版本范围 | 引入的优化 | 说明 |
|---|---|---|
| 9.0 – 9.1 | Buffer Pool 持久化增强 | 定期将热页列表保存至磁盘，重启后加载，消除冷启动预热 |
| 9.2 – 9.3 | Change Buffer 分时限流合并 | 将集中式合并改为分散在时间窗口，平滑 I/O 波动 |
| 9.4 | Log Buffer 在线调整 | innodb_log_buffer_size支持SET GLOBAL，无需重启 |
| 9.5 | Undo Buffer 独立拆分 | Redo 与 Undo 的刷盘路径解耦，MVCC 场景更可控 |
| 9.6 | Atomic I/O 实验性支持 | 对 NVMe SSD 启用原子写入，可绕过 Doublewrite Buffer |
6.2 重要特性详解
Buffer Pool 持久化（9.0）
虽然 5.6/5.7/8.0 已支持innodb_buffer_pool_dump_now，但需要手动触发。9.0 引入自动后台 dump（默认每 10 秒检查变化），并将热页列表以更紧凑的格式存储。实例重启后，加载速度比旧方式快数倍，适合云环境频繁弹性伸缩的场景。
LRU 多级淘汰（9.2）
传统的 LRU 采用“中点插入”策略，但面对扫描密集型负载仍可能污染缓存。9.2 引入了三级热度区分：低热度页优先淘汰，中热度页次之，高热度页尽量保留。这使得热点数据在缓存中停留时间更长。
Change Buffer 分时限流（9.3）
此前 Change Buffer 的合并由一个后台线程周期性全量触发，容易产生 I/O 尖峰。9.3 改为分布式调度：将合并任务拆分成小批次，均匀分配到秒级时间窗口内，写 I/O 负载更加平滑，对 SSD 寿命也更友好。
Atomic I/O 试验（9.6）
现代 NVMe SSD 支持“原子域”（Atomic Write Unit），例如保证 16KB 写入的完整性。9.6 开始，InnoDB 能够检测此类设备，并自动将数据页直接写入数据文件，无需先写 Doublewrite Buffer。这消除了双写带来的写放大，提升写密集型负载性能。此功能在 9.7 LTS 中得到正式支持和默认启用。
七、MySQL 9.7 LTS：十年演进的集大成者（2026）
2026 年 4 月 21 日，MySQL 9.7.0 LTS发布。它吸收了 8.4 LTS 的稳定性、9.x Innovation 的所有优化，并最终完成了 InnoDB 模块化与硬件自适应架构的完整落地。
7.1 内存架构的最终形态
| 组件 | 9.7 LTS 最终特性 |
|---|---|
| Buffer Pool | 细粒度锁 + 持久化热页 + 三级 LRU + 多实例在线调整（对业务影响极小） |
| Change Buffer | 默认关闭（none），但可按需开启并支持分时限流合并 |
| Log Buffer | 默认 64MB，支持在线调整，Undo Buffer 独立刷盘 |
| AHI | 分区锁（默认 8 分区，可在线修改），支持单表开关，多级淘汰策略 |
7.2 磁盘架构的最终形态
| 组件 | 9.7 LTS 最终特性 |
|---|---|
| 数据字典 | 独立 Data Dictionary Tablespace（mysql.ibd），不再依赖 ibdata1 |
| Undo | 独立多 Undo 表空间，支持 SQL 动态管理，在线自动截断 |
| 临时表空间 | 多文件 + 会话级隔离，支持事务，可独立回收 |
| Doublewrite | 被 Atomic I/O 替代（在 NVMe 设备上默认禁用），消除写放大 |
| General Tablespaces | 成熟稳定，支持多表共享，可放置于任何存储路径 |
7.3 Atomic I/O 的正式引入
在 9.7 LTS 中，Atomic I/O 已从实验性转为生产可用。当底层 NVMe SSD 报告支持原子写入时，InnoDB 自动将 Doublewrite Buffer 关闭，数据页直接写入目标文件。这一改变：
- 减少 100% 的额外写入（原本每页写两次）；
- 降低写放大系数，延长 SSD 寿命；
- 提升写密集型负载吞吐量（例如大量 INSERT、UPDATE）。
对于无法保证原子写入的设备（如机械硬盘或较老的 SSD），9.7 LTS 仍可启用传统的 Doublewrite Buffer 模式，保持兼容性。
八、全景对照表：从 5.7 到 9.7 的关键跨越
| 架构维度 | MySQL 5.7 | MySQL 8.0 (8.0.27+) | MySQL 8.4 LTS | MySQL 9.7 LTS |
|---|---|---|---|---|
| 数据字典 | ibdata1 + .frm（双份） | 事务数据字典（mysql.ibd） | 稳定化事务字典 | 独立字典表空间 |
| Undo 管理 | 默认 ibdata1，可独立但不灵活 | 默认独立，支持在线截断 | 继承 8.0 | 多表空间 + 自适应扩展策略 |
| Doublewrite | 固定在 ibdata1 | 独立双写文件（8.0.20） | 独立双写 | Atomic I/O 替代 |
| Change Buffer | 默认 all，集中合并 | 仍为 all，但调度改进 | 默认 none | 默认 none + 分时限流 |
| AHI | 全局单锁 | 分区锁（8.0） | 分区锁 | 分区锁 + 单表开关 + 在线调整分区数 |
| Buffer Pool | 预热比例可调 | 持久化支持 |
