gh-ost不依赖触发器，通过解析row格式binlog同步变更，主库写入压力显著降低；pt-online-schema-change则全程依赖insert/update/delete触发器，高qps下易成性能瓶颈并导致copying rows卡顿。
gh-ost不走触发器，主库写入压力直接少一个量级
pt-online-schema-change 依赖 INSERT/UPDATE/DELETE 三个触发器同步变更，所有写入操作都会额外触发一次对影子表的 REPLACE INTO 或 DELETE IGNORE。高 QPS 下，触发器本身就成了瓶颈，容易拖慢主库、卡住 COPYING ROWS 进度。
gh-ost 完全绕开触发器，它伪装成从库，直接消费主库的 binlog（要求 binlog_format=ROW），把 DML 解析成等价操作写入影子表。原表的 SELECT FOR UPDATE、长事务、大事务都不会被 gh-ost 干扰——它不抢锁、不加行锁、不读原表数据。
- 触发器模式下，
Threads_running常飙到 100+，pt-online-schema-change自身就成了负载源 - gh-ost 的 CPU 和 IO 压力集中在 binlog 解析和影子表写入，主库 SQL 线程几乎无感知
- 若主库已开启
sync_binlog=1和innodb_flush_log_at_trx_commit=1，触发器还会放大 fsync 压力
gh-ost能主动控速，pt-osc只能被动等追平
pt-online-schema-change 在 COPYING ROWS 阶段必须等触发器 backlog 清空才能切换，而 backlog 积压是常态：写入突增、网络抖动、从库延迟都可能让它卡在 99.9% 不动。你看到 SHOW PROCESSLIST 里一堆 INSERT SELECT 和触发器线程，就是它在硬扛。
gh-ost 的流控是实时的：--max-load 检查的是主库状态，--throttle-control-replicas 可指定某台从库来判断是否限速，甚至支持 --postpone-cut-over-flag-file 手动冻结切换——这意味着你能按业务节奏控制节奏，而不是被工具反向绑架。
- pt-osc 的
--max-lag是“检查从库延迟→暂停拷贝→再检查”，容易引发锯齿式卡顿 - gh-ost 默认每 500ms 检查一次复制位点，延迟波动时自动降速，推进更平滑
- 若从库延迟 > 30 秒，pt-osc 可能反复暂停/恢复 10+ 次，总耗时翻倍；gh-ost 仍持续拷贝，只在最终切换前等从库追上
gh-ost回滚快、中断安全，pt-osc中断易留脏数据
pt-online-schema-change 中断后，触发器不会自动清理，影子表、触发器、临时表可能残留。重试前得手动 DROP TRIGGER、DROP TABLE，稍有遗漏就导致后续同步错乱或主键冲突。
gh-ost 中断即终止，所有中间状态（影子表、临时库）默认带唯一前缀（如 _mytable_20260604123456_gho），下次运行会自动跳过或覆盖。强制中断后执行 gh-ost --assume-rbr --max-load="Threads_running=1" --critical-load="Threads_running=50" --skip-foreign-key-checks --execute 即可续跑，不用人工擦屁股。
- gh-ost 支持
--exact-rowcount强制校验行数，避免因应用层长事务跨 binlog 位置导致漏同步 - pt-osc 的触发器一旦出错（比如字段类型不兼容），整个流程会卡死，
KILL后还可能留下未提交的触发器事务 - gh-ost 切换只做一次
RENAME TABLE，毫秒级完成；pt-osc 切换前还得清空触发器队列，不可控因素更多
但 gh-ost 的约束更硬，别踩这些坑
gh-ost 稳的前提是环境合规。它不像 pt-osc 那样“能跑就行”，几个关键条件不满足，启动直接失败或行为异常：
- 必须开启
binlog_format=ROW，且server_id唯一，否则报错Cannot find binlog stream - 不支持直接
MODIFYENUM/SET字段，得先转成VARCHAR再改，否则报unsupported column type - 原表不能有外键（
--allow-on-master强行绕过会失效），也不能含全文索引、GIS 列 - 如果应用用了
autocommit=0+ 显式事务，且事务横跨 gh-ost 的 binlog 位点，可能漏同步——这时必须加--exact-rowcount
真正难的不是选工具，而是看懂自己表的结构、主从拓扑、binlog 配置和业务事务模型。gh-ost 稳，是因为它把不确定性尽可能推给了前提条件；pt-osc 容错强，代价是把风险留在了运行时。
