适用场景

大表变更最容易出事：一条 ALTER 锁表几十分钟，业务直接不可用。正确做法是用支持在线变更的工具、限速、分阶段执行，并提前确认从库延迟与磁盘空间。

配置步骤（在线变更工具实操）

# 1) 变更前评估
mysql biz -e 'SELECT table_name, table_rows, round(data_length/1024/1024) AS data_mb, round(index_length/1024/1024) AS idx_mb FROM information_schema.tables WHERE table_schema = DATABASE() ORDER BY data_length DESC LIMIT 10;'
df -h /var/lib/mysql

# 2) gh-ost 方式（示例）
gh-ost --host=127.0.0.1 --user=ddl --password=*** \
  --database=biz --table=biz_order \
  --alter='add column channel varchar(32) default NULL, add index idx_channel(channel)' \
  --max-load='Threads_running=30' --critical-load='Threads_running=60' \
  --chunk-size=1000 --max-lag-millis=1500 --allow-on-master --execute

# 3) 原生 Online DDL（8.0 部分场景支持 INPLACE）
ALTER TABLE biz_order ADD COLUMN channel varchar(32) DEFAULT NULL, ALGORITHM=INPLACE, LOCK=NONE;

# 4) 变更后验证
SHOW CREATE TABLE biz_order\G
SELECT COUNT(*) FROM biz_order;
SHOW SLAVE STATUS\G   # 看 Seconds_Behind_Master

关键参数与建议

  • 先评估：表大小、行数、索引数量、是否有外键与触发器
  • 工具选择：MySQL 8.0 原生 Online DDL 或 gh-ost / pt-osc，视版本与场景定
  • 限速：控制每秒处理行数，避免从库延迟与磁盘 IO 打满
  • 空间：在线变更期间要额外空间存放影子表，磁盘水位 < 70% 再动手
  • 从库：变更期间关注主从延迟，必要时暂停或降低速率
  • 窗口：业务低峰执行，准备好暂停与回退步骤
  • 验证：变更后核对表结构、行数、关键查询执行计划

容易踩的坑

  • 直接在生产执行 ALTER，锁表导致业务中断
  • 磁盘空间不足，变更到一半失败留下影子表
  • 不限速，从库延迟涨到几小时
  • 变更期间同时跑备份，IO 争抢更严重
  • 变更完不核对行数，做了半天发现变更失败
  • 用工具但没给 metadata lock 留时间，反复重试

验证与巡检

# 变更后核对
SHOW CREATE TABLE biz_order\G                     # 结构与索引
SELECT COUNT(*) FROM biz_order;                    # 行数与变更前对比
EXPLAIN SELECT * FROM biz_order WHERE channel='web'; # 执行计划
SHOW SLAVE STATUS\G | grep -E 'Seconds_Behind|Running'

# 清理残留（确认无影子表与触发器）
SHOW TABLES LIKE '_biz_order%';
SHOW TRIGGERS FROM biz LIKE 'biz_order%';
  • 巡检：无残留表与触发器、主从延迟恢复正常、变更记录归档

小结

大表变更验收：结构变更生效、行数一致、主从无延迟堆积、业务查询性能无退化，且有完整的变更记录。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。