MySQL 8.0.12及以上支持Instant ADD COLUMN，但仅限末尾加列、允许NULL或带DEFAULT值、无FULLTEXT等复杂索引等严格条件满足时才真正毫秒完成。
千万级表加字段，慢不是因为“数据多”，而是因为MySQL默认要重写全表。只要避开重建，就能从小时级降到毫秒级。
MySQL 8.0+ 是否支持 Instant ADD COLUMN？
必须先确认版本和操作类型——只有 MySQL 8.0.12 及以上才支持 Instant ADD COLUMN，且仅限以下场景：
-
ADD COLUMN必须加在表末尾（不能插在已有列中间） - 新列必须允许
NULL或带DEFAULT值（不能是NOT NULL且无默认值） - 不支持
ADD COLUMN ... AFTER xxx这类定位语法 - 不支持全文索引、空间索引、生成列等复杂类型
满足条件时，执行 ALTER TABLE t ADD COLUMN c INT DEFAULT 0 真的只改元数据，耗时
MySQL 5.7 或不满足 Instant 条件时怎么办？
这时必须绕过全表拷贝。核心思路：不改原表结构，用 Online DDL + 参数控制锁级别：
- 强制使用
ALGORITHM=INPLACE（避免COPY模式） - 显式指定
LOCK=NONE（允许并发读写；若报错“requires exclusive lock”，说明该操作不支持无锁，需换方案） - 避开触发重建的操作：比如给
TEXT列加NOT NULL会失败，换成NULL+ 默认值再分步UPDATE - 注意磁盘空间：
INPLACE仍需额外空间存变更日志，建议预留 ≥1.2 倍原表大小
示例：ALTER TABLE orders ADD COLUMN status TINYINT DEFAULT 0, ALGORITHM=INPLACE, LOCK=NONE;
为什么 pt-online-schema-change 有时比原生命令更稳？
它本质是“影子表”逻辑，不依赖 MySQL 内部 DDL 实现，因此规避了版本限制和隐式锁升级问题：
- 对 MySQL 5.6/5.7/8.0 全版本兼容
- 自动处理主从延迟、binlog 格式、外键约束等边界情况
- 可中断、可限速（
--max-load/--chunk-size），适合线上敏感业务 - 但要注意：DDL 过程中会多一张临时表，占用双倍磁盘；且所有写请求经由触发器转发，轻微增加 QPS 压力
典型命令：pt-online-schema-change --alter "ADD COLUMN ext_data JSON" D=shop,t=orders --execute
大列（如 TEXT、BLOB）加字段特别慢，怎么破？
真正拖慢的不是“加列”，而是“为每行分配并初始化大存储空间”。关键对策是延迟填充：
- 先加
NULL列：ALTER TABLE log ADD COLUMN content TEXT（快） - 后续用小批量
UPDATE填充，每次 ≤ 1 万行，避开长事务和 undo 日志膨胀 - 避免直接加
NOT NULL DEFAULT '...'大字符串——MySQL 会试图把默认值写满每一行物理记录 - 如果字段长期为空，考虑拆到单独的扩展表，用
JOIN或应用层关联，减少主表宽度
千万级表上，一个 1KB 的 DEFAULT 值会让 DDL 时间从毫秒跳到数小时。
真正容易被忽略的点：即使用了 Instant，后续第一次 SELECT * 读取旧行时，MySQL 仍要动态补默认值——如果应用大量全字段查询，CPU 开销会上升。别只盯着 DDL 耗时，要看后续查询是否变慢。
