MySQL 8.0 原子 DDL 指 DDL 操作具备原子语义：失败即完整回滚，不残留临时文件、不破坏数据字典一致性；其核心是将表定义写入 InnoDB 数据字典表（如 mysql.tables），并与表空间创建、binlog 写入绑定于同一隐式 XA 事务中。
MySQL 8.0 的原子 DDL 不是“事务性 DML 那种可显式 BEGIN/COMMIT 的事务”，而是指 DDL 操作本身具备原子语义：失败即回滚，不留半成品表、不残留临时文件、不破坏数据字典一致性。
为什么 CREATE TABLE 失败后看不到残留表结构？
因为表定义不再写入 .frm 文件，而是作为一条完整记录插入到数据字典表 mysql.tables 和 mysql.columns 中，并与 InnoDB 引擎层的表空间创建（.ibd）和 binlog 写入绑定在同一隐式 XA 事务中。任一环节失败，整个事务回滚 —— 包括字典表插入、文件系统操作、binlog 记录。
常见错误现象：
-
ERROR 1005 (HY000): Can't create table `db`.`t` (errno: 13)（权限不足）→ 表名不会出现在INFORMATION_SCHEMA.TABLES中 - 磁盘满导致
ALTER TABLE ... ADD COLUMN中断 → 不会留下mysql.innodb_table_stats中过期的统计信息残影
哪些 DDL 语句真正实现了原子性？
不是所有 DDL 都原子。MySQL 8.0 原子 DDL 覆盖绝大多数核心操作，但有明确边界：
- ✅ 原子：
CREATE TABLE,DROP TABLE,ALTER TABLE,CREATE INDEX,DROP INDEX,CREATE VIEW,DROP VIEW,CREATE DATABASE,DROP DATABASE - ❌ 非原子（仍为语句级）：
TRUNCATE TABLE（本质是 DROP + CREATE）、RENAME TABLE（部分场景依赖文件系统原子重命名）、ANALYZE TABLE、OPTIMIZE TABLE - ⚠️ 特殊：
CREATE OR REPLACE VIEW是原子的，但它是先DROP再CREATE的组合动作，整体成功或整体失败
判断依据看官方文档的 “Atomic Data Definition Statement” 列表，而非直觉。
数据字典表（如 mysql.tables）能直接 SELECT 吗？
不能，普通用户会被拒绝访问。这些表受严格保护，即使你有 SELECT 权限也无法执行：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT * FROM mysql.tables;
返回错误：ERROR 3716 (HY000): The 'mysql.tables' table is a system table and cannot be accessed directly.
正确方式始终是通过标准接口：
- 查表结构用
SHOW CREATE TABLE或DESCRIBE - 查元数据用
INFORMATION_SCHEMA.TABLES/COLUMNS（它们是基于数据字典的只读视图） - 调试时需启动 mysqld 时加
--debug=d,skip_dd_table_access_check并用SET SESSION debug='+d,skip_dd_table_access_check'，仅限开发环境
升级到 MySQL 8.0 后，旧备份还能还原吗？
不能直接还原到 8.0 实例。因为 5.7 及之前版本的数据字典是分散的 .frm、.opt、mysql 库中的 MyISAM 表；而 8.0 要求所有元数据统一存于 InnoDB 的 mysql.ibd 中。mysqld 启动时会检测数据字典版本，若发现不匹配，会拒绝启动并报错：
ERROR 3724 (HY000): Cannot upgrade the data dictionary from version X to Y.
必须走官方升级路径：mysqld --upgrade=FORCE 或使用 mysql_upgrade（已弃用，推荐原地升级脚本）。跳过这步，连服务都起不来。
最容易被忽略的是：升级前未停写、未校验 mysql 系统库完整性，或误删了 mysql.ibd —— 这会导致整个数据字典不可恢复，远比丢一张业务表严重。
