INSTANT ADD COLUMN完全不碰二级索引，因为二级索引叶子节点只存主键值和非空列数据，新列未出现在任何索引定义中，引擎无需扫描或更新索引项，聚簇索引也仅在行头增加位图标识和默认值指针，B+树结构零变动。
INSTANT ADD COLUMN 为什么完全不碰二级索引
它根本不会修改任何二级索引，因为二级索引（B-Tree、FULLTEXT、SPATIAL）的叶子节点只存主键值 + 非空列数据，而新列未出现在任何已有索引定义中。InnoDB 引擎连扫描都不扫，更谈不上重建或重排。
常见错误现象：有人误以为“加列后索引变慢”，其实那往往是后续建索引或查询条件变更导致的，和 INSTANT 本身无关。
- 聚簇索引也不动——旧行物理格式不变，只是在行头加了个位图标识和默认值指针
- 所有现有索引指针依然有效，B+ 树结构零变动
-
SELECT * FROM t返回新列值，是运行时动态拼接，不是磁盘上真写了
加列和建索引必须分两步执行
INSTANT 的瞬时性只保留在纯加列操作里；一旦混入建索引，整条 ALTER TABLE 就会 fallback 到 INPLACE 或更糟的 COPY，可能锁表几分钟。
正确做法是严格分离：
- ✅ 第一步：
ALTER TABLE t ADD COLUMN status TINYINT DEFAULT 0, ALGORITHM=INSTANT; - ✅ 第二步：
ALTER TABLE t ADD INDEX idx_status (status), ALGORITHM=INPLACE; - ❌ 错误写法：
ALTER TABLE t ADD COLUMN x INT, ADD INDEX idx_x (x);—— 即使单看加列满足 INSTANT 条件，也会静默降级
第二步建索引仍需遍历聚簇索引，耗时与数据量正相关；INSTANT 不改变这一点，它只守住“加列”这一步的毫秒级响应。
哪些硬限制一碰就让 INSTANT 失效
INSTANT 是“全有或全无”，漏掉任意一条就会静默 fallback，而不是报错提醒。最容易被忽略的是：
- 表上有
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
验证方式不能只看 SHOW CREATE TABLE，还得查真实行格式：SELECT ROW_FORMAT FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE NAME = 'database/t1'（注意库名小写+斜杠）。
INSTANT 实际改了什么，又没改什么
它只动三处元数据，不动一行用户数据：
- 在
mysql.ibd和innodb_sys_columns等系统表中插入新列定义（类型、默认值、偏移位置） - 在表的 instant columns 元信息区生成一个“虚拟默认值描述符”，每张表最多存 64 次 instant 操作记录
- 后续
INSERT时动态填充缺失列；SELECT时按需拼接老行与新列定义
这意味着 DESCRIBE t1 立刻可见新列，但物理存储里老数据依然没有这个字段——这是运行时合成，不是补全。真正影响性能的环节（比如建索引、大范围 UPDATE）依然得走常规路径，INSTANT 不掩盖这些成本。
