MySQL 8.0 数据字典强制依赖InnoDB，因原子DDL、崩溃安全、多版本可见性及集群一致性均需其事务、redo/undo日志和MVCC能力；MyISAM等非事务引擎语义缺失，无法支撑元数据统一管理。
MySQL 8.0 数据字典不是“选 InnoDB”，而是根本没得选
因为数据字典的原子性、崩溃安全、多版本可见性和跨节点一致性，全部依赖 InnoDB 的底层能力。MyISAM、MEMORY 或任何非事务引擎在架构层面就无法支撑——这不是配置问题，是存储引擎语义缺失导致的硬性不兼容。
崩溃后元数据不一致的根源在 .frm 文件与引擎各自维护表定义
MySQL 5.7 及之前版本中，Server 层写 .frm 文件，InnoDB 引擎又在 ibdata1 里存一份表结构，两者无事务保障。一旦 ALTER TABLE 过程中崩溃，就会出现：
-
.frm已更新但 InnoDB 字典未提交 → 启动时报Table 'db.t1' doesn't exist - InnoDB 已建好新索引，
.frm还是旧版 →INFORMATION_SCHEMA.COLUMNS显示字段缺失或类型错乱 - 备份只拷了
.ibd却漏掉.frm，或反之 → 表不可用且无法自动修复
MySQL 8.0 把 mysql.tables、mysql.columns、mysql.indexes 等全部收编为 InnoDB 系统表，所有变更走 redo/undo 日志，失败自动回滚，不留半成品。
原子 DDL 背后是数据字典表的事务性写入
所谓“原子 DDL”，本质是把一条 SQL 拆成对多个数据字典表的 DML 操作（如插入 mysql.tables、mysql.columns），再包裹进同一个 InnoDB 事务。例如：
CREATE TABLE t1 (id INT) ENGINE=InnoDB
会同时写入：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
mysql.tables（表名、引擎、字符集等） -
mysql.columns（字段名、类型、默认值等） -
mysql.indexes（主键定义）
任意一步失败（磁盘满、权限不足），整个事务 rollback，mysql 库无残留，t1.ibd 也被自动清理。这依赖 sql/dd/ 目录下的数据字典 API（如 dd::Table::store()）与 InnoDB 层深度集成，不是加个 BEGIN 就能模拟的。
SET PERSIST 和 MGR 集群都直接依赖 mysql.persisted_variables 表
SET PERSIST innodb_buffer_pool_size = 2G 看似只是改个配置，实际发生两件事：
- InnoDB 把新值写进
mysql.persisted_variables表，并刷入 redo log - 主线程读该表，生成/覆盖
mysqld-auto.cnf并 fsync 到磁盘
如果这个系统表用 MyISAM，宕机时可能只写了一半，重启后生成错误配置导致实例无法启动；并发执行多个 SET PERSIST 还会互相覆盖。MGR 集群同理：ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin 是硬拦截，因为 Paxos 共识要求 binlog event 解析结果完全一致、崩溃后可精确重放——MyISAM 没有 undo log，没有 MVCC，也没有事务日志，根本做不到。
真正容易被忽略的是：你看到的“元数据统一”“原子 DDL”“持久化变量”，背后全是 mysql 库下那些 InnoDB 系统表在扛着。它们不是可插拔组件，而是 MySQL 8.0 Server 层运行的前提。
