在业务持续运行的背景下，对线上数据表执行字段变更（如增加列、修改类型或添加索引）不能简单停机操作。数据表锁表会阻断读写，直接影响业务连续性。本文面向IDC与云环境运维人员，梳理不停机变更字段的常用工具和实操要点，帮助降低变更风险。

为什么需要不停机变更

传统ALTER TABLE在MySQL等数据库中通常需要获取元数据锁，大表变更耗时数百秒甚至更久。期间写入请求会被阻塞，造成接口超时或服务不可用。对于7×24小时业务，必须采用在线变更方案，通过复制数据或并行执行的方式完成结构更新，同时保持业务无感知。

常用工具与原理

gh-ost

gh-ost（GitHub Online Schema Transition）通过二进制日志增量同步实现不停机变更。它创建一个影子表，将原表数据批量复制，同时监听binlog事件持续应用增量变更，最终通过原子换表完成切换。gh-ost不依赖触发器，对主库压力较小。

pt-online-schema-change

percona-toolkit提供的pt-online-schema-change通过创建新表并利用触发器同步增量数据，完成复制后交换表名。它成熟稳定，但触发器可能带来额外开销。工具会根据负载自动调整复制速度。

实操前准备

无论选用哪个工具，都需要完成以下检查。

• 确认变更类型：自增列、外键、唯一索引等特殊变更可能限制在线执行。
• 检查磁盘空间：影子表或临时表需要足够空间，建议预留原表数据体积的1.5倍以上。
• 评估主从延迟：在线变更会额外产生复制流量，延迟过大会影响一致性。
• 权限准备：需要SELECT、INSERT、UPDATE、DELETE、CREATE、ALTER、DROP等权限，以及binlog读取权限。
• 低峰期执行：即使不停机，也应选择业务低峰期，减少负载叠加风险。

实操步骤（以gh-ost为例）

1. 下载并配置：安装gh-ost二进制，准备生产库连接信息和binlog位置。
2. 预检模式：使用--test-on-replica在从库上测试，不会修改主库。
3. 执行变更：执行类似gh-ost --host=主库 --database=app --table=orders --alter="ADD COLUMN status TINYINT" --execute的命令。工具会展示进度和流量控制参数。
4. 控制复制速度：通过--max-load和--max-lag-millis限制对主库的影响。
5. 切换表：复制完成后，gh-ost会原子切换表名，期间只产生极短暂写锁定。
6. 清理工作：确认新表正确后删除旧表或保留备份。

注意事项与风险控制

• 外键限制：若表存在外键，gh-ost和pt-osc的处理方式不同，需提前评估。
• 触发器冲突：pt-osc需要在原表创建触发器，若已有触发器可能冲突。
• 监控连接数和线程状态：确保不会超出数据库最大连接数。
• 多次增量同步：对于写入压力大的表，切换前需确认延迟趋近于零。

回滚与应急预案

在线变更本质上是可逆的：只要保留原表，就能快速切回。建议执行前在测试环境完整演练，并记录原表结构、触发器及授权信息。若线上出现异常磁盘占用、锁竞争或复制风暴，立即使用工具提供的停止控制（如gh-ost的--panic-flag）中止进程。

不停机变更字段是保障高可用业务的关键能力。运维团队应结合监控告警和自动化平台，将操作标准化，从而在满足业务迭代需求的同时，最大限度降低对线上服务的影响。选择适合自身架构的工具，并遵循严谨的变更流程，才能确保在复杂环境中稳定运行。