instant add column 仅加速满足条件的 alter table ... add column 操作本身，不加速崩溃恢复、主从同步或 pitr；其生效需严格满足引擎、行格式、索引、默认值等全部硬性条件，否则退化为 inplace 或 copy。
INSTANT ADD COLUMN 本身不用于“恢复”，它不是备份/恢复机制，也不能加速崩溃恢复、主从同步恢复或 PITR（时间点恢复）。如果你在故障后想靠加字段来“加速恢复”，那方向错了——它只加速**结构变更本身**，且仅限满足条件的 ALTER TABLE ... ADD COLUMN 操作。
真正容易混淆的点是：有人把“加字段后业务快速上线”误认为“恢复快”，其实只是 DDL 不卡住服务而已。下面直说关键操作和陷阱。
为什么 INSTANT 不能加速 crash recovery 或 binlog replay？
崩溃恢复（crash recovery）依赖 redo log 重放，跟表结构元数据无关；binlog 回放执行的是原始 DML/DDL 语句，ALGORITHM=INSTANT 只影响执行时长，不改变日志内容或回放逻辑。MySQL 启动时不会因为某张表用过 INSTANT 就跳过 redo 扫描或页校验。
哪些场景下误以为“INSTANT 加速了恢复”？
常见于以下三类实际需求，但本质不是恢复，而是规避恢复阻塞：
- 主从延迟高时，想在线加监控字段 → 用
ALGORITHM=INSTANT避免在从库长时间锁表，防止 DDL 成为延迟瓶颈 - 灾备切换后需快速补字段支持新应用逻辑 → 若原表满足条件，
ADD COLUMN秒级完成，比等 COPY 算法跑完更早进入可用状态 - 滚动升级后发现缺字段，需紧急补全 → INSTANT 让你不用等维护窗口，直接在业务高峰期执行（前提是满足全部约束）
INSTANT 能生效的硬性条件必须逐条验证
哪怕只差一条，就会退化为 INPLACE（遍历每行填充）甚至 COPY（全表重建），此时不仅不加速，反而引发 I/O 飙升、主从延迟、锁表等问题。必须检查：
- 引擎必须是
InnoDB（MyISAM/MEMORY直接报错ERROR 1845 (0A000)） - 行格式必须是
DYNAMIC或COMPRESSED（查SELECT ROW_FORMAT FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE NAME = 'db/tbl'） - 不能有
FULLTEXT索引（存在即强制COPY，哪怕只加TINYINT） - 默认值只能是字面量或
DEFAULT NULL（DEFAULT NOW()、DEFAULT (id + 1)全部拒绝 INSTANT） - MySQL 8.0.29+ 才支持非末尾加列；旧版本必须用
AFTER last_col或不写位置 - 单条语句只能含
ADD COLUMN，混DROP INDEX、MODIFY COLUMN或逗号分隔多操作都会失败
如何确认 INSTANT 真的生效了？
别信执行耗时，也别信自己写了 ALGORITHM=INSTANT —— 唯一可靠方式是执行后立刻查：
SHOW CREATE TABLE tbl_name;
输出中必须明确出现 ALGORITHM=INSTANT。如果没这行，或者显示 ALGORITHM=INPLACE，说明已退化。再辅以监控：information_schema.INNODB_METRICS 中 dml_rows_inserted 在加列期间是否突增 —— 突增说明正在重写数据行，INSTANT 已失效。
