MySQL 8.0的原子DDL特性保证了DDL操作的完整性，要么全部执行成功，要么全部回滚，不会出现之前版本中DDL执行到一半留下残留元数据的问题。但在实际使用中，不少用户会遇到原子DDL操作执行失败并报错的情况，其中很大一部分原因和表空间一致性、存储引擎配置有关。
原子DDL的基本机制
原子DDL的核心是将DDL操作的元数据变更、存储引擎层的表空间操作、二进制日志写入放在同一个事务中执行。执行过程中如果任何一步出现错误，整个事务会回滚，恢复到操作前的状态。如果表空间本身存在不一致，或者存储引擎不支持原子DDL，就会导致操作失败。
常见报错类型与触发原因
- 表空间不存在或不一致：报错信息中常出现
表空间不存在、表空间ID不匹配等提示，通常是之前的非原子DDL操作残留了损坏的表空间文件，或者手动修改了数据目录下的表文件导致。 - 存储引擎不支持：报错提示
存储引擎不支持原子DDL，MySQL 8.0中只有InnoDB存储引擎完整支持原子DDL，MyISAM等其他引擎执行DDL时可能触发这类错误。 - 元数据锁冲突：原子DDL执行时会加元数据锁，如果有长事务持有相关表的元数据锁，会导致DDL等待超时失败，这类问题也会伴随表空间相关的间接报错。
检查表空间一致性的方法
首先可以通过MySQL的系统表查询表空间的基本信息，确认表空间状态是否正常。
查询系统表获取表空间信息
执行以下SQL可以查看所有表的表空间配置和状态：
-- 查询所有表的表空间信息，包含表名、存储引擎、表空间名
SELECT
TABLE_SCHEMA,
TABLE_NAME,
ENGINE,
TABLESPACE_NAME
FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');
如果查询到某张表的ENGINE字段为空，或者TABLESPACE_NAME指向的表空间不存在，就说明表空间可能存在问题。
校验表空间文件完整性
可以登录服务器进入MySQL的数据目录，找到对应库的文件夹，检查.ibd表空间文件是否存在，文件大小是否正常。也可以通过InnoDB的检查工具验证文件完整性，执行以下命令：
-- 进入MySQL数据目录，假设数据目录为/var/lib/mysql cd /var/lib/mysql/目标库名 -- 检查对应的ibd文件是否存在 ls -lh 目标表名.ibd
检查存储引擎配置
首先需要确认当前实例的默认存储引擎是否为InnoDB，执行以下SQL查看：
-- 查看默认存储引擎配置 SHOW VARIABLES LIKE 'default_storage_engine';
如果返回值不是InnoDB，需要在配置文件my.cnf中修改default_storage_engine=InnoDB，重启实例生效。如果是单独某张表使用了非InnoDB存储引擎，可以执行以下SQL修改表的存储引擎：
-- 将目标表的存储引擎修改为InnoDB ALTER TABLE 目标库名.目标表名 ENGINE=InnoDB;
修复原子DDL操作失败的步骤
表空间不一致修复
如果是表空间ID不匹配或者文件损坏，可以尝试以下步骤修复：
- 先对数据库做全量备份，避免修复过程中数据丢失。
- 如果是残留的坏表，可以先尝试删除表，如果删除失败，可以手动删除数据目录下对应的
.ibd和.frm（如果是MySQL 8.0以下版本遗留的表）文件，然后重启实例。 - 重启后重新执行之前的DDL操作，确认是否正常执行。
存储引擎问题修复
如果是存储引擎不支持导致的报错，按照前面的方法修改表的存储引擎为InnoDB后，重新执行DDL操作即可。如果修改存储引擎时也报错，可以先导出表数据，删除坏表，再重新建表导入数据。
避免原子DDL失败的最佳实践
- 统一使用InnoDB存储引擎，避免混用其他不支持原子DDL的存储引擎。
- 不要手动修改MySQL数据目录下的表空间文件，所有表结构变更都通过SQL语句执行。
- 执行DDL操作前，先确认没有长事务持有相关表的元数据锁，可以通过
SHOW PROCESSLIST查看当前运行的线程， kill掉阻塞的事务。 - 定期备份数据库，出现问题时可以快速恢复到之前的状态。
注意：修复表空间操作属于高风险操作，操作前一定要做好数据备份，避免出现不可逆的数据丢失。