INSTANT ADD COLUMN 不触发索引重建，仅更新数据字典和行头位图；二级索引无需修改因叶子节点不含新列，聚簇索引结构零变动；加列与建索引必须分步执行才能保持瞬时性。
INSTANT ADD COLUMN 对大表索引重建“有帮助”，这个说法容易误导——它根本不会触发索引重建，更谈不上“加速”重建。真正关键在于：它让「加列」和「建索引」这两步彻底解耦，避免了传统流程中因加列导致的连锁重建风险。
INSTANT ADD COLUMN 为什么完全不碰二级索引
- 二级索引（B-Tree、FULLTEXT、SPATIAL）叶子节点只存主键值 + 非空列数据，而新列未出现在任何已有索引定义中 → 引擎无需更新任何索引项
- 聚簇索引的物理行格式被扩展为“动态头+固定数据体”，旧行记录不重写 → 所有现有索引指针依然有效，B+ 树结构零变动
-
INSTANT只在数据字典（如mysql.innodb_table_stats、innodb_sys_columns）里插入列元数据，同时在行记录头部加一个位图标识和默认值指针
这意味着：哪怕你有一张 50GB 的表、12 个二级索引，执行 ALTER TABLE t ADD COLUMN status TINYINT DEFAULT 0, ALGORITHM=INSTANT，所有索引都不需要扫描、不重排、不锁表、不生成临时文件。
加列后立即建索引，会不会被 INSTANT 拖累？
不会，但要注意操作方式：
-
✅ 正确：分两步，且各自独立
ALTER TABLE t ADD COLUMN is_archived TINYINT DEFAULT 0, ALGORITHM=INSTANT;
ALTER TABLE t ADD INDEX idx_archived (is_archived), ALGORITHM=INPLACE;
第二步建索引是标准INPLACE流程，不影响第一句的瞬时性 -
❌ 错误：混在一条语句里
ALTER TABLE t ADD COLUMN x INT DEFAULT 0, ADD INDEX idx_x (x);
即使单看加列满足INSTANT条件，整条语句也会 fallback 到INPLACE或COPY，可能锁表几分钟 ⚠️ 注意：建索引本身仍需遍历聚簇索引，耗时与数据量正相关；
INSTANT不改变这一点，它只保住了“加列”这一步的毫秒级响应
容易被忽略的硬限制：一碰就退化
INSTANT 是“全有或全无”，漏掉任意一条，就会静默降级（除非显式指定 ALGORITHM=INSTANT）：
- 表上有
FULLTEXT索引 → 直接强制COPY，哪怕只是加一个TINYINT - 行格式是
ROW_FORMAT=COMPRESSED或KEY_BLOCK_SIZE > 0→ 不支持 - MySQL 8.0.12–8.0.27 中，表没有显式主键且无
NOT NULL UNIQUE列 → 用隐式主键则禁用INSTANT - 默认值是
NOW()、UUID()、子查询或表达式 → 不支持，必须是字面量或显式DEFAULT NULL - 行版本数已达 64（查
TOTAL_ROW_VERSIONS）→ 报错ERROR 4092，必须重建表重置
最常踩的坑是：以为“8.0 就行”，没检查 SHOW CREATE TABLE 里有没有 FULLTEXT，也没验证真实 ROW_FORMAT（SHOW CREATE TABLE 显示的可能是旧缓存值，得查 INFORMATION_SCHEMA.INNODB_TABLES）。
