MySQL 8.0.12及以上版本中，对千万级大表添加字段可实现秒级完成：在末尾添加允许NULL且不含非空DEFAULT值的列时，支持ALGORITHM=INSTANT，仅需修改元数据；如果包含NOT NULL DEFAULT，则会降级为INPLACE或COPY操作。需要提前检查引擎，显式指定ALGORITHM=INSTANT和LOCK=NONE，若失败则可降级使用pt-osc或gh-ost。
MySQL千万级大表执行DDL操作，如果不加干预，基本都会锁表数小时。但只要选对方案并满足校验条件，10分钟内完成、业务无感是完全可能的。
结论先行：给千万级大表添加字段，并不只有硬扛锁表这一条路。从MySQL 8.0.12版本起，只要操作满足条件，字段就能在秒级内完成添加。关键在于明确何时可以使用快速通道，何时必须选择其他方案。
判断 ALGORITHM=INSTANT 是否可用
自MySQL 8.0.12起，对于在表末尾添加允许NULL且不含DEFAULT值的字段，支持使用ALGORITHM=INSTANT。该操作无需拷贝数据或重建表，仅修改元数据，理论上可在毫秒级完成。
但前提是添加的字段必须允许NULL。一旦使用NOT NULL DEFAULT 'xxx'，即使只是短字符串，MySQL也会执行全表扫描以填充默认值，从而从“分分钟完成”退化为“数小时的折磨”。关键检查点如下：
- 执行前务必通过
SELECT * FROM information_schema.INNODB_TABLES WHERE NAME LIKE '%your_table%'确认表引擎为InnoDB - 测试语句必须显式指定：
ALTER TABLE your_table ADD COLUMN remark VARCHAR(255), ALGORITHM=INSTANT, LOCK=NONE; - 如果出现错误
ALGORITHM=INSTANT is not supported for this operation，则表示该操作不支持INSTANT，需要降级为INPLACE或改用其他工具
pt-online-schema-change 触发器写入延迟的应对策略
当INSTANT方案不可行时，pt-osc是许多团队的备选方案。它在主表上创建INSERT/UPDATE/DELETE三类触发器来捕获变更，然后分批将数据迁移到新表。该机制本身不会阻塞主流程，但在高并发写入场景下，触发器执行缓慢可能导致chunk迁移卡顿、binlog日志积压以及从库延迟。
以下是一些实际经验：
- 添加参数
--max-load="Threads_running=25"主动限流，防止触发器消耗过多连接资源 - 禁用外键检查：使用
--no-check-alter并手动确保新旧表外键一致性，否则触发器会因外键约束检查而变慢 - 避免主键非自增场景：如果使用UUID或复合主键，必须为
--chunk-index指定高效索引，否则WHERE范围扫描将退化为全表扫描
gh-ost 切换前最后几秒为何会出现抖动
gh-ost 最终的 RENAME TABLE 是原子操作，按理不会锁表。但实际中许多团队反映，切换瞬间仍会出现“抖动”。这并非锁表，而是应用层的短暂失效：原表不可写、新表就绪、应用连接重连，这个窗口期可能因应用层DNS缓存、连接池未及时感知新表结构而导致短暂失败。
因此，以下关键点必须提前验证：
- 必须开启
binlog_format=ROW，否则 gh-ost 无法解析变更，将回退到 polling 模式，大幅增加延迟 - 使用
--cut-over-lock-timeout-seconds=3控制重试等待上限，避免陷入锁竞争 - 上线前在测试环境执行一次
--dry-run，观察gh-ost-status输出中的throttle-control-reason是否频繁触发
不要忽略主从延迟和连接池刷新
再平滑的DDL操作，在主从架构下也无法避免binlog回放延迟。尤其是gh-ost和pt-osc都依赖binlog同步，主库切换完成后，从库可能尚未追上，导致读请求打到从库时查不到新字段。
以下是容易踩坑的地方：
- 切表前用
SHOW SLA VE STATUS\G确保Seconds_Behind_Master = 0，否则先stop sla ve等追平 - 应用连接池（如 HikariCP）需要配置
connection-test-query=SELECT 1和合理的validation-timeout，避免复用旧连接执行包含新字段的SQL时出现Unknown column错误 - 如果使用了读写分离中间件（如 ShardingSphere、MyCat），DDL操作后需要手动触发元数据刷新，否则路由规则仍会按旧结构进行匹配
真正困难的从来不是调通工具，而是将“表结构已变更”这一信息同步到数据库、中间件、应用连接池、监控告警、甚至开发人员的本地SQL脚本中。漏掉任何一环，都可能在凌晨三点触发一个 Column not found 错误。
