根本原因是mysql 8.0+将元数据存入innodb系统表并纳入acid事务，崩溃时由innodb恢复机制自动回滚整个ddl事务，确保表结构始终为完整旧态或完整新态，杜绝“一半新增列、一半缺失索引”的中间态。
MySQL 中 ALTER TABLE 在 InnoDB 上更安全，根本原因不是“它能加字段”，而是它把元数据变更纳入了 InnoDB 事务体系——失败即回滚，不留中间态。
为什么 InnoDB 的 ALTER TABLE 不会留下“半改不改”的残血表
MySQL 5.7 及以前，ALTER TABLE 是三步裸奔：改 .frm 文件 → 更新 InnoDB 内部字典 → 写 binlog。任意一步中断（比如断电、KILL -9），就会出现客户端报 Table definition has changed, please retry transaction，但 DBA 查不到问题在哪——InnoDB 认为结构已变，.frm 还是旧的，binlog 没记录，从库同步直接卡死。
InnoDB 在 8.0+ 把所有元数据（列、索引、表空间）全搬到 mysql.columns、mysql.tables 等 InnoDB 系统表里。一次 ADD COLUMN 实际是一次标准事务：插入新列记录 + 更新表版本字段 + 写 binlog 事件，全部打包提交。崩溃后，InnoDB 崩溃恢复机制自动回滚整个事务，重启后你看到的永远是完整旧结构或完整新结构。
哪些 ALTER TABLE 操作真正受原子性保护
别被“MySQL 8.0 支持原子 DDL”带偏——只有明确标注 Atomic DDL supported: Yes 的操作才进事务流程：
-
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。它们失败时可能已写入部分元数据，无法整体回滚。
为什么 ALGORITHM=INSTANT 不等于原子，但值得优先用
ALGORITHM=INSTANT 是性能优化手段，不是事务保障机制。它跳过拷表阶段，只改 mysql.columns 等系统表，锁持有时间极短（毫秒级），但依然依赖原子 DDL 流程兜底——如果中途崩溃，仍靠事务回滚清理。
使用前必须确认：
- MySQL 版本 ≥ 8.0.12
- 新增列不能是首列、不能含
DEFAULT表达式、不能是虚拟列 -
innodb_strict_mode=ON（否则可能绕过长度校验，后续INSERT报错）
执行时加 LOCK=NONE 显式声明，避免 MySQL 自动降级为 INPLACE 或 COPY。
大表改结构时，InnoDB 的“安全”不等于“无影响”
原子性只保证“全有或全无”，不缓解锁表本身。哪怕 ADD COLUMN 走 INSTANT，最后仍需短暂加 MDL（metadata lock）写锁，阻塞其他 DDL；若表上有长事务未提交，ALTER 会卡在 Waiting for table metadata lock 状态，持续占用连接。
生产环境必须：
- 查
information_schema.INNODB_TRX，确认目标表无运行超 60 秒的未提交事务 - 设
lock_wait_timeout = 5，避免无限等待 - 超 1GB 表一律不用原生命令，改用
pt-online-schema-change或gh-ost
最常被忽略的一点：原子 DDL 依赖 innodb_force_recovery=0。如果数据库启用了强制恢复模式（值为 1–6），原子事务根本无法启动，ALTER 直接失败。
