适用场景

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

配置步骤（变更窗口与回退设计）

# 1) 变更分级
# L1 只加索引/加可空字段：低风险，低峰执行
# L2 改字段类型/改索引：中风险，需从库验证
# L3 改主键/拆表：高风险，需停机或灰度

# 2) 回退设计
#   - 保留变更前表结构快照：SHOW CREATE TABLE 存档
#   - 加字段可直接 DROP COLUMN 回退
#   - 改类型回退可能重建表，需提前测算耗时

# 3) 窗口内步骤
#   a. 通知业务方
#   b. 备份/快照
#   c. 执行变更（限速）
#   d. 验证（结构/行数/查询）
#   e. 通知恢复

# 4) 变更记录：时间、执行人、语句、耗时、影响

关键参数与建议

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

容易踩的坑

  • 变更没备份，回退无从下手
  • 未通知业务方，变更期间业务方以为系统故障
  • 回退步骤只是「反着改回去」，没有实测过
  • 变更窗口太短，中途停止留下不一致状态
  • 改字段类型未评估重建耗时，窗口内做不完
  • 变更记录不写，事后无法复盘

验证与巡检

# 回退可行性验证（测试库执行）
# 1) 用备份恢复结构与数据
# 2) 执行回退语句并计时
# 3) 记录回退耗时，写入变更方案
  • 巡检：变更方案含回退步骤与耗时、变更记录归档、遗留问题闭环

小结

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

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