如何针对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分钟内完成、业务无感是常态。

确认 ALGORITHM=INSTANT 是否可用

MySQL 8.0.12+ 添加允许 NULL 的字段（不含 DEFAULT 值或含 DEFAULT NULL）可走元数据变更，真正“零拷贝”。但一旦带 NOT NULL DEFAULT 'xxx'，哪怕只是字符串，就会退化为全表扫描填充，默认触发 ALGORITHM=INPLACE 甚至 COPY。

• 执行前务必用 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 触发器写入延迟怎么压

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 无法解析变更，会 fallback 到 polling 模式，大幅增加延迟
• 用 --cut-over-lock-timeout-seconds=3 控制重试等待上限，避免卡在锁竞争里
• 上线前在测试环境跑一次 --dry-run，观察 gh-ost-status 输出中 throttle-control-reason 是否频繁触发

别忽略主从延迟和连接池刷新

再平滑的 DDL，在主从架构下也绕不开 binlog 回放延迟。尤其 gh-ost 和 pt-osc 都依赖 binlog 同步，主库切完，从库还没追上，读请求打到从库就会查不到新字段。

• 切表前用 SHOW SLAVE STATUSG 确保 Seconds_Behind_Master = 0，否则先 stop slave 等追平
• 应用连接池（如 HikariCP）要配置 connection-test-query=SELECT 1 和合理 validation-timeout，避免复用旧连接执行含新字段的 SQL 报 Unknown column
• 如果用了读写分离中间件（如 ShardingSphere、MyCat），DDL 后需手动触发元数据刷新，否则路由规则仍按旧结构匹配

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