MySQL 8.0 InnoDB 引擎实现底层重构：AUTO_INCREMENT 持久化至 redo log 和系统表，doublewrite 支持独立路径与模式配置，系统表全 InnoDB 化并移除 .frm 文件，redo/undo 加密可独立控制且密钥管理至关重要。
MySQL 8.0 的 InnoDB 引擎不是“小修小补”，而是从数据持久性、崩溃恢复、加密粒度到元数据管理都做了底层重构。很多线上故障和配置异常，根源就在这些被忽略的变更上。
自增值不再丢：AUTO_INCREMENT 持久化机制变了
以前重启 MySQL，AUTO_INCREMENT 值会回退到表中最大 ID + 1；现在它写入 redo log 并在 checkpoint 时落盘到系统表 mysql.innodb_sys_tables 中。这意味着：
- 手动执行
ALTER TABLE t AUTO_INCREMENT = 1000后，即使宕机重启也依然生效 - 事务回滚后分配过的 ID 不会被重用（比如插入后 rollback，下一个 ID 是 1001 而非重复用 1000）
-
UPDATE自增列本身会影响后续插入起点：把某行的id改成 5000，下一条插入就会从 5001 开始
⚠️ 注意：这改变了部分业务对“ID 连续性”的隐含假设，尤其依赖自增 ID 做分库分表路由或幂等判断的系统，需重新验证逻辑。
innodb_doublewrite 不再是单文件，路径和行为都可配
8.0.20+ 版本起，doublewrite buffer 从共享表空间里移出，变成独立文件组，默认生成在数据目录下，文件名形如 doublewrite_0001。关键控制项包括：
-
innodb_doublewrite_dir：指定存放路径，支持绝对路径（如/ssd/mysql/dw） -
innodb_doublewrite_files：默认 2 个，建议 SSD 环境保持 ≥2，HDD 可设为 1 减少随机写 -
innodb_doublewrite_mode（8.0.30+）：值为DETECT_ONLY时只校验不恢复，适合只读从库压测场景
? 错误配置风险：若未显式设置 innodb_doublewrite_dir，而数据目录挂载在低 IOPS 存储上，doublewrite 文件写入可能成为写瓶颈。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
系统表全部 InnoDB 化，mysql 库不再有 MyISAM 表
执行 SELECT DISTINCT ENGINE FROM information_schema.tables WHERE TABLE_SCHEMA = 'mysql'，结果只剩 InnoDB。这意味着：
- 所有权限操作（
CREATE USER、GRANT）都走事务，不会出现“改了一半权限就崩了导致状态不一致” - 系统表锁从表级变为行级，高并发创建用户/角色时不再卡住整个
mysql库 - 元数据统一进事务性数据字典（
mysql.ibd），.frm文件彻底消失
⚠️ 容易被忽略的一点：备份工具若还依赖扫描 .frm 或硬编码 MyISAM 系统表结构（比如某些老版本 pt-table-checksum），会在 8.0 下直接报错或漏检。
Undo 和 Redo 都能加密，但加密开关是独立控制的
加密不再是“开或不开”的粗粒度操作。各组件加密能力与开关如下：
- Redo 日志加密：由
innodb_redo_log_encrypt单独控制（8.0 起默认 OFF） - Undo 日志加密：需同时开启
innodb_undo_log_encrypt和innodb_undo_tablespaces > 2 - Doublewrite 文件加密：仅当所属表空间已加密时自动启用（8.0.23+）
? 关键限制：如果启用了 redo 加密但没配密钥轮换策略（keyring_file 或 keyring_encrypted_file），密钥丢失即等于数据不可恢复——这点比表空间加密更致命，因为 redo 是实例级强依赖。
