MySQL 8.0中CREATE TABLE、DROP TABLE、ALTER TABLE默认原子：依赖InnoDB数据字典事务性，元数据与文件操作统一提交或回滚，不需额外配置，但仅限单条语句且须为InnoDB表。
CREATE TABLE、DROP TABLE、ALTER TABLE 这类语句在 MySQL 8.0 中默认就是原子的，不需要额外“创建”或开启开关。你只要用的是 InnoDB 表、MySQL 8.0+、且没混用不支持的引擎或语法，DDL 就天然具备原子性。
CREATE TABLE 为什么一执行就原子？
- MySQL 8.0 把数据字典全移到了
InnoDB表里（比如mysql.tables），元数据操作本身就能走事务。 - 执行
CREATE TABLE t1 (id INT) ENGINE=InnoDB时，内部会：- 先写 DDL 日志到隐藏表
mysql.innodb_ddl_log - 再建
.ibd文件、更新字典、写 binlog - 最后统一提交或崩溃时自动回滚整个流程
- 先写 DDL 日志到隐藏表
- 如果中途 crash，重启后不会残留空
.ibd或半截.frm（因为根本没.frm了）
常见错误现象：
你在 MySQL 5.7 看到 ERROR 1050 (42S01): Table 't1' already exists 后再 SHOW TABLES 却发现表没建成功——这种“部分成功”在 8.0 的 CREATE TABLE 中不会发生。
DROP TABLE 多表操作的原子边界在哪？
-
DROP TABLE t1, t2, t3是原子的：要么全部删掉，要么一个都不删（哪怕其中某个表不存在，整条语句也会报错并回滚）。 - 但
DROP TABLE t1; DROP TABLE t2;是两条独立语句：第一条成功、第二条失败，t1 就真没了。 - 关键点在于：原子性只作用于单条 DDL 语句内，不是跨语句的事务。
容易踩的坑：
用脚本批量删表时写成循环执行多条 DROP TABLE，误以为“只要加了 IF EXISTS 就安全”——其实 DROP TABLE IF EXISTS t1 成功后服务器宕机，t2 就永远删不掉了。
ALTER TABLE 哪些操作能原子，哪些不能？
支持原子性的 ALTER TABLE 操作（需 ENGINE=InnoDB）：
- 添加/删除列（
ADD COLUMN/DROP COLUMN） - 添加/删除索引（
ADD INDEX/DROP INDEX） - 修改列类型（只要不触发 ALGORITHM=COPY，例如从
VARCHAR(10)改成VARCHAR(20)） - 重命名表（
RENAME TO）
不支持原子性的典型情况：
- 涉及非 InnoDB 表（如
ENGINE=MyISAM），直接报错ER_ALTER_OPERATION_NOT_SUPPORTED - 使用
ALGORITHM=COPY强制重建（比如把TEXT列改成VARCHAR(100)），此时原子性退化为“字典+日志”层面，但文件操作仍可能残留临时文件（极少见，仅 crash 极端场景）
性能影响提示：
原子 DDL 不等于“快”。ALTER TABLE 加索引仍要扫描全表，只是失败时不会留烂摊子。
原子 DDL 最容易被忽略的一点：它不解决业务逻辑一致性。比如你先 ALTER TABLE users ADD COLUMN balance DECIMAL，再应用层跑数据迁移脚本填值——这两步之间没有原子性保障。DDL 的原子，只管自己这一行 SQL 的元数据、文件、binlog 三者对齐，不管你的应用代码。
