MySQL千万级大表平滑DDL：避免锁表技巧

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 是否可用

从8.0.12版本起，MySQL针对末尾添加允许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 SLAVE STATUS\G 确保 Seconds_Behind_Master = 0，否则先暂停从库等待追平
• 应用连接池（如HikariCP）需配置 connection-test-query=SELECT 1 和合理的 validation-timeout，避免复用旧连接执行含新字段的SQL时报 Unknown column
• 若使用读写分离中间件（如ShardingSphere、MyCat），DDL后需手动触发元数据刷新，否则路由规则仍按旧结构匹配

真正困难的地方从来不是工具调通，而是将“表结构已变更”这一事实，同步到数据库、中间件、应用连接池、监控告警、甚至开发同学的本地SQL脚本中——遗漏任意一环，都可能在凌晨三点触发一个 Column not found 告警。