MySQL 8.0原子DDL更安全，因其将元数据统一存入InnoDB，使变更具备事务特性（undo log、crash recovery、行级锁），彻底避免.frm与.ibd不一致等崩溃后状态错乱问题。
mysql.columns、mysql.tables、mysql.indexes 这些表现在都存于 InnoDB，所以元数据变更本身具备事务性——这是 InnoDB 数据字典稳定性的根本原因。MyISAM 没有这个能力。
MySQL 8.0 的元数据不再分散在文件和不同引擎里
MySQL 5.7 及以前，元数据是“三头马车”：表结构存 .frm 文件（文件系统）、用户权限存 MyISAM 表（mysql.user 等）、InnoDB 内部字典又另有一套（SYS_TABLES）。一旦崩溃，很容易出现 .frm 已更新但 ibdata1 字典没写完，或者主库 DDL 成功、从库因 .frm 残留解析失败。
MySQL 8.0 把所有核心元数据统一迁入 InnoDB 引擎的 mysql 库下，包括：
-
mysql.columns、mysql.tables、mysql.indexes：字段、表、索引定义 -
mysql.schemata、mysql.tablespaces：库、表空间信息 -
mysql.procs、mysql.triggers、mysql.views：过程、触发器、视图
这些表不再是只读字典，而是可被 DDL 实时修改的事务表。例如 ALTER TABLE t ADD COLUMN c INT 会原子性地插入新列记录、更新表元信息、补充索引定义——全部打包在一个内部事务中提交。
崩溃时能回滚，不是“不坏”，而是“坏不了”
InnoDB 元数据表的稳定性不来自“不会出错”，而来自“出错即回滚”。关键支撑有三：
- 所有元数据写入走 InnoDB 的事务路径，有
undo log，crash recovery 可回滚未完成操作 - DDL 执行前先写
mysql.innodb_ddl_log（不可见系统表），用于物理层回滚（比如删文件失败时恢复原文件） - 行级 X 锁保证并发 DDL 不互相干扰，避免元数据状态错乱
对比 MyISAM：mysql.user 这类表仍是 MyISAM 引擎，不支持事务，DROP USER 中断可能导致权限残留或缺失，且无自动恢复机制。
为什么你查不到 mysql.innodb_ddl_log 却必须知道它
mysql.innodb_ddl_log 是原子 DDL 的“最后保险丝”，但它被设计为完全隐藏——你无法 SELECT、DESCRIBE 或 DROP 它。它的存在只为 crash recovery 服务：当 DDL 在中间步骤崩溃（如重命名文件成功但更新 mysql.tables 失败），InnoDB 启动时会扫描该日志，反向执行补偿操作（比如删掉已创建的新文件）。
这意味着：
- 你不需要手动干预元数据一致性
- 但如果你绕过 MySQL Server 直接操作文件系统（如 cp / rm
.ibd），这个日志就失效了，稳定性保障归零 -
innodb_force_recovery模式下该日志也不生效，此时 DDL 被禁止
MyISAM 元数据“看起来快”，其实是放弃校验换来的假象
MyISAM 的 .frm 文件是纯文本，mysql.user 是 MyISAM 表，读写不经过事务、无 checksum、无 redo。这带来两个后果：
- 单次 DDL 很快（比如
CREATE TABLE就是写一个文件+插一行 MyISAM） - 但多步操作（如
RENAME TABLE）没有原子性：可能.frm改名成功，但mysql.tables没更新，导致后续SHOW TABLES看不见这张表
这种“快”是以牺牲一致性为代价的。而 InnoDB 的“慢一点”换来的是：任意时刻你能相信 mysql.tables 和磁盘上的 .ibd 结构一定对得上。
真正容易被忽略的点是：稳定性不等于“永不崩溃”，而在于崩溃后能否自动回到一致状态。InnoDB 把元数据当作普通业务数据来管，MyISAM 则把它们当成配置文件来用——后者在高可用场景下风险更高。
