instant ddl无需扫描或复制数据，因其仅修改数据字典（如mysql.columns表），新增列信息通过行版本标识动态解析，默认值按需填充，不触碰用户数据页。
因为 INSTANT DDL 不操作数据页，只改数据字典，锁表时间自然压到毫秒级。
INSTANT 为什么不需要扫描或复制数据
MySQL 8.0 彻底重构了数据字典，把表结构（列定义、默认值、顺序等）全存进 mysql.columns、mysql.tables 这类系统表里，而不是像老版本那样依赖磁盘上的 .frm 文件。INSTANT 算法就建立在这个基础上：
- 执行
ALTER TABLE ... ADD COLUMN时，MySQL 只往mysql.columns插一条新记录，不碰任何用户数据页 - 后续读取旧数据行时，InnoDB 根据当前字典定义动态补默认值或
NULL，不提前回填 - 连行格式头都不用改——新增列信息靠新增的“版本位”或“行版本号”标识，老数据照样能解析
锁类型和持续时间对比：INSTANT vs INPLACE vs COPY
锁行为差异直接决定业务是否感知到变更：
-
ALGORITHM=COPY：全程持有 MDL 写锁（X），阻塞所有 DML 和 DDL，锁表时间 = 数据拷贝耗时 -
ALGORITHM=INPLACE：准备阶段和提交阶段各持一次短 MDL 锁，但执行阶段仍可能重建索引或重写行头，锁持续几十毫秒到数秒不等 -
ALGORITHM=INSTANT：仅在元数据更新前后持两次极短 MDL 锁（通常
INSTANT 的支持范围和常见失效场景
它快，但不是万能的。一旦操作超出元数据范畴，MySQL 就自动降级到 INPLACE 或 COPY：
- 支持的操作：
ADD COLUMN（末尾）、DROP COLUMN、RENAME COLUMN、CHANGE COLUMN（仅改名，不改类型或约束） - 不支持的操作：
MODIFY COLUMN（哪怕只是改NOT NULL）、ALTER COLUMN SET DEFAULT（已设默认值后修改）、加主键/索引、改字符集、调字段顺序（AFTER） - 容易踩坑：
ALTER TABLE t ADD COLUMN c INT NULL DEFAULT 0是 INSTANT；但紧接着ALTER TABLE t MODIFY COLUMN c INT NOT NULL DEFAULT 0就会退化为 INPLACE，耗时飙升
INSTANT 的真正门槛不在语法，而在对“元数据变更”边界的理解——只要没动真实数据的存储布局，它就能瞬时完成；一旦涉及行结构重排、索引重建或默认值物理填充，锁就回来了。
