MySQL 8.0 中并非所有 ALTER TABLE 都具备原子性，仅官方标注 Atomic DDL supported: Yes 的操作受保护，如末尾 ADD COLUMN、DROP COLUMN（非全文索引列）、ADD/DROP INDEX（不含 FULLTEXT）、同库 RENAME TABLE、ENGINE=InnoDB；而 MODIFY/CHANGE COLUMN、OPTIMIZE TABLE、跨库 RENAME TABLE 等不支持原子性，失败时无法整体回滚。
ALTER TABLE 操作在 MySQL 8.0 中默认具备原子性，但仅限于官方明确标注为 Atomic DDL supported: Yes 的子集——误以为所有 ALTER TABLE 都能回滚，是线上事故最常踩的坑。
哪些 ALTER TABLE 真正受原子性保护？
不是语法合法就等于事务安全。MySQL 8.0 原子 DDL 的支持范围严格受限于存储引擎和操作类型：
-
ADD COLUMN（末尾添加，且不触发ALGORITHM=COPY） -
DROP COLUMN（InnoDB 表，非全文索引列） -
ADD INDEX/DROP INDEX（不含FULLTEXT） -
RENAME TABLE（同一 schema 内） -
ALTER TABLE ... ENGINE=InnoDB（隐式重建）
以下操作明确不支持原子性：MODIFY COLUMN、CHANGE COLUMN、OPTIMIZE TABLE、跨库 RENAME TABLE。它们失败时可能已修改部分元数据，无法整体回滚。
为什么显式 START TRANSACTION 有时反而危险？
单条 ALTER TABLE 在 MySQL 8.0 中自动包裹在隐式事务中；手动加事务只在多条 DDL 连续执行时有意义，但有严苛前提：
- 所有语句都必须属于原子 DDL 支持的操作——混入一条
MODIFY COLUMN，整个事务立即失败，且已执行的原子操作不会回滚 -
CREATE TABLE+INSERT+ALTER TABLE组合进一个事务是安全的 -
ALTER TABLE+TRUNCATE TABLE不行，因为TRUNCATE是 DDL，不参与多语句事务的原子联动
执行前必须验证的三件事
原子性只管“改完或不改”，不管“能不能改”。以下问题仍会导致阻塞或失败：
- 查
information_schema.INNODB_TRX，确认目标表没有运行超 60 秒的未提交事务；否则ALTER会卡在Waiting for table metadata lock - 设
SET lock_wait_timeout = 5，避免无限等待 MDL 锁；超时后报错退出，而非长期占用连接 - 对大表优先尝试
ALGORITHM=INSTANT（仅限ADD COLUMN、SET DEFAULT、RENAME COLUMN），它跳过拷表阶段，锁持有时间最短——但注意：INSTANT≠ 原子，只是快；失败时依然回滚
崩溃后如何验证原子性是否生效？
别依赖错误信息判断。服务器异常重启后，用这两条命令交叉验证：
-
SHOW CREATE TABLE t1—— 看结构是否完整旧或完整新（绝不会出现“新增了列但索引丢失”） -
SELECT * FROM information_schema.INNODB_TABLES WHERE NAME LIKE 'your_db/t1'—— 对比mysql.columns和mysql.indexes中记录是否一致
真正容易被忽略的是：原子 DDL 要求 innodb_force_recovery=0 且 mysql.innodb_ddl_log 表可写；若磁盘满或权限异常，DDL 会直接报 ER_DDL_LOG_ERROR 并失败——此时连原子性的入口都进不去。
