INSTANT加字段失效是因为迁移后存在隐性不兼容项导致退化；常见原因包括残留FULLTEXT索引、COMPACT行格式、使用FIRST关键字或表达式默认值，需清理并验证SHOW CREATE TABLE确认ALGORITHM=INSTANT。
INSTANT加字段为什么在迁移后反而失效？
MySQL 8.0升级后，ADD COLUMN没变快，甚至比5.7还慢——大概率不是版本问题，而是迁移过程中遗留的“隐性不兼容项”被INSTANT算法直接拦截。INSTANT不是默认开启的加速器，而是一套严格守门的元数据变更协议，任何一项条件不满足，就立刻退化为COPY或INPLACE。
常见迁移后触发退化的硬性条件：
-
FULLTEXT索引未清理：哪怕只有一列带FULLTEXT，ALGORITHM=INSTANT会直接报错ERROR 3104 (HY000) - 表行格式仍是
COMPACT：老版本建的表迁移后未显式执行ALTER TABLE ... ROW_FORMAT=DYNAMIC，INSTANT拒绝生效 - 用了
FIRST关键字：如ADD COLUMN x INT DEFAULT 0 FIRST，INSTANT强制要求新列必须追加末尾（AFTER last_col或省略位置） - 默认值含表达式：
DEFAULT NOW()、DEFAULT UUID()、DEFAULT (col_a + 1)都无法走INSTANT，必须改用字面量如DEFAULT '2026-01-01'
如何确认你的ADD COLUMN真的走了INSTANT？
别信执行耗时，也别信自己写的ALGORITHM=INSTANT——MySQL会静默降级，且不报错（除非你显式指定并触发硬拦截）。唯一可靠验证方式是查元数据：
执行SHOW CREATE TABLE tbl_name，在输出中搜索ALGORITHM=INSTANT。如果没出现，说明已退化；若出现ALGORITHM=INPLACE或压根没提ALGORITHM，就是没走INSTANT。
补充验证：在加字段前后，执行SELECT COUNT(*) FROM information_schema.INNODB_METRICS WHERE NAME = 'dml_rows_inserted'。若该值暴涨，说明正在填充旧数据行，INSTANT已失效。
迁移后启用INSTANT必须做的三件事
升级到8.0只是前提，不是终点。要让INSTANT真正可用，需主动清理迁移残留：
- 删掉所有
FULLTEXT索引：DROP INDEX ft_idx ON tbl_name，加完字段后再重建（INSTANT不支持全文索引共存） - 统一行格式：
ALTER TABLE tbl_name ROW_FORMAT=DYNAMIC，注意该操作本身是INPLACE，但会短暂锁表，建议低峰执行 - 检查并重写DDL语句：去掉
FIRST，把DEFAULT CURRENT_TIMESTAMP改成DEFAULT '0000-00-00 00:00:00'或NULL，确保新列定义只含字面量默认值
INSTANT对线上业务的真实影响边界
INSTANT确实能做到毫秒级加字段、无I/O、不占磁盘空间，但它只解决“新增列”这一个点。一旦涉及后续操作，脆弱性立刻暴露：
- 加完字段后立刻
UPDATE旧数据填充该列？不行——INSTANT不写旧行，但UPDATE会触发全表扫描+逐行回写，瞬间变成高负载操作 - 加的是
NOT NULL列且表里已有百万行？MySQL 8.0.12之前版本可能误判需填充，默认拒绝INSTANT；8.0.29+虽支持，但仍要求默认值是字面量 - 想在加列同时改列类型或删索引？INSTANT只认纯
ADD COLUMN，混入其他alter_specification直接报错ERROR 3106
INSTANT不是万能膏药，它是精确制导的元数据手术刀——只动字典，不动数据页。任何试图“顺便处理数据”的念头，都会让它当场失效。
