在线改表工具是什么
对几千万行以上的大表执行 ALTER TABLE，原生在线 DDL 虽然不长时间锁表，但重建过程中的 IO 与临时空间压力仍可能影响业务。gh-ost 与 pt-online-schema-change（pt-osc）是两类成熟的外部工具：做法都是先建一张新表、把数据搬过去、同时持续同步变更，最后用原子 RENAME 换表。区别在增量同步方式：pt-osc 用触发器，gh-ost 解析 binlog 不建触发器。两者都支持限流、暂停与中止。
基本信息
| pt-osc | Percona Toolkit 组件，靠触发器捕获增量 |
|---|---|
| gh-ost | 独立二进制，靠解析 binlog 捕获增量，可在从库读取 |
| 共同点 | 建影子表 + 增量同步 + 原子 RENAME 切换 |
| 限流 | 按负载指标（如 Threads_running）自动暂停拷数据 |
| 切换保障 | 先加唯一键避免数据不一致，切换前后做行数比对 |
典型使用场景
- 上亿行大表加索引：原生 DDL 影响窗口过长时改用工具分阶段执行
- 大表改列类型：字符集或类型变更通常需要重建表，工具能把影响摊到长时间窗口
- 在线补列：为宽表新增列时避免整体重建带来的空间峰值
- 业务高峰不可停：非高峰窗口有限时，靠限流参数让工具在压力上升时自动让路
- 演练与回滚：工具过程可暂停或中止，比一次性提交的原生 DDL 更可控
gh-ost 使用示意
gh-ost 使用示意
# 先干跑，只输出计划不实际执行
gh-ost --host=127.0.0.1 --user=osc --password='***' \
--database=appdb --table=orders \
--alter='ADD COLUMN memo VARCHAR(200)' \
--max-load='Threads_running=50' --critical-load='Threads_running=200' \
--chunk-size=1000 --dry-run
# 确认无误后改 --execute 真正执行
# pt-osc 的等价思路（Percona Toolkit）
pt-online-schema-change --alter 'ADD COLUMN memo VARCHAR(200)' \
--max-load Threads_running=50 --critical-load Threads_running=200 \
--user=osc --password='***' D=appdb,t=orders --dry-run两种工具对比
| 维度 | pt-osc | gh-ost |
|---|---|---|
| 增量同步 | 在源表上创建触发器 | 解析 binlog，不建触发器 |
| 源表写放大 | 触发器带来额外写入开销 | 较轻，可读从库 binlog 减轻主库压力 |
| 已有触发器 | 与现有触发器冲突，需特殊处理 | 不冲突，但仍要评估 binlog 格式要求 |
| 切换方式 | 原子 RENAME | 原子 RENAME |
| 依赖 | Percona Toolkit | 独立二进制，需 binlog 访问权限 |
两种工具都会在磁盘上同时存在源表与影子表，所需额外空间接近源表体积加上增量部分，执行前必须先确认剩余空间够用。
限流参数必须按业务实际负载设置：不限流地跑大表改表，会把主库 IO 与内存抢到业务超时，风险高于原生 DDL。