pt-online-schema-change在大表上卡住或失败的根本原因是其依赖触发器实时捕获变更，当源表写入压力高、主从延迟大或存在长事务时，工具会主动暂停拷贝以保护系统，而非性能缺陷。
pt-online-schema-change 为什么会在大表上卡住或失败
很多DBA一看到pt-osc卡住，第一反应是工具性能不行。其实，这恰恰是它的保护机制在起作用。问题的根源不在于工具慢，而在于其核心设计：它依赖在源表上创建触发器来实时捕获数据变更。一旦源表的写入压力过高、主从复制延迟变大，或者存在未提交的长事务，工具就会主动暂停数据拷贝——这是一种自我保护，而非程序缺陷。在日志里，你通常会反复看到“Waiting for the sla ve to catch up”或“Pausing due to high load”这样的提示。
所以，在决定使用pt-osc之前，有几个关键限制必须提前确认，否则很容易半途而废：
- 主键是硬性要求：源表必须拥有主键或唯一索引，否则工具会直接退出。
- 触发器冲突：目标数据库不能已存在同名或冲突的触发器，否则会报错“ERROR 1442 (HY000): Can't update table in stored function/trigger”。
- 外键约束需处理：如果表有外键关联，工具默认会报错“Foreign key constraints are not supported”。通常需要加上
--alter-foreign-keys-method=auto参数让它自动处理。 - 磁盘空间要充足：务必预留至少2倍于原表大小的磁盘空间，因为临时表、原表以及激增的binlog日志都会占用大量空间。
gh-ost 如何绕过触发器限制并降低主库压力
那么，gh-ost是如何解决这些痛点的呢？它的设计思路很巧妙：完全摒弃触发器。gh-ost通过模拟一个从库，直接解析主库的binlog来获取DML变更，再异步应用到它自己创建的临时表中。这套机制带来了两个直接好处：一是天然兼容那些已经存在触发器的旧系统，二是彻底避免了创建触发器带来的额外锁竞争和性能抖动。
当然，天下没有免费的午餐。gh-ost这套基于binlog的机制，也带来了一些新的依赖条件：
- binlog格式必须为ROW：这是准确解析变更内容的前提，STATEMENT或MIXED格式都不行。
- binlog_row_image需为FULL：在MySQL 5.6及以上版本，这通常是默认值。如果设置为MINIMAL，UPDATE和DELETE操作可能会丢失旧值，导致数据不一致。
- 账号权限要求高：需要一个具备
REPLICATION SLA VE和REPLICATION CLIENT权限的数据库账号，以便能读取binlog。 - 功能限制：早期版本不支持修改主键列、分区表或包含ENUM/SET类型的列。虽然部分新版本已支持，但生产环境使用前务必进行实测。
一个典型的gh-ost执行命令长这样：gh-ost --host=xxx --database=test --table=t_user --alter="ADD COLUMN c4 VARCHAR(32)" --chunk-size=1000 --max-load="Threads_running=25" --allow-on-master --execute
什么时候该选 pt-osc，什么时候必须切 gh-ost
面对两个工具，到底该如何选择？其实有一条相对清晰的分界线。
如果你的线上环境同时满足以下所有条件，那么pt-osc依然是可靠的首选：表有主键、无触发器、外键约束少、运维团队对Percona Toolkit这套工具链非常熟悉，并且业务能接受rename切换时那几百毫秒的元数据锁（MDL）。
但是，只要出现以下任何一种情况，就应该毫不犹豫地切换到gh-ost：
- 表上存在业务强依赖的触发器，你不敢也不能在改表前删除它。
- 主库的CPU或IO利用率长期处于70%以上的高位，无法再承受触发器带来的额外开销。
- 主从延迟波动较大，pt-osc会因此频繁暂停，导致整个操作耗时变得不可预测。
- 操作环境是阿里云RDS、腾讯云CDB这类托管数据库服务，它们通常禁用了触发器或SUPER权限。
需要补充一点：gh-ost在最后的rename切换阶段同样需要获取元数据锁，但其持续时间通常更短、更可控。而pt-osc在rename之前，还会默认执行一次ANALYZE TABLE来更新统计信息，这个操作有时会意外触发表的全面统计重算，反而可能拖慢最终切换速度。
线上执行前最容易被忽略的三件事
参数调优和备份的重要性大家都知道，但真正让很多线上操作阴沟里翻船的，往往是下面这三个容易被忽略的细节。可以说，90%的意外失败都与此有关：
- 没检查 max_allowed_packet：如果表中包含TEXT、BLOB这类大字段，默认的4MB数据包大小可能导致数据拷贝时的INSERT语句失败。建议将会话级的
max_allowed_packet临时调大到64M或更高。 - 没确认超时参数：
wait_timeout和interactive_timeout这两个参数，决定了连接的空闲超时时间。在数据缓慢拷贝的阶段，工具连接可能因为长时间空闲而被服务器断开。建议在操作前，将会话的超时时间临时调高至28800秒（8小时）。 - 没注意客户端的autocommit行为：一些应用程序框架（ORM）或监控工具在初始化数据库连接时，会自动设置
autocommit=1。这会干扰gh-ost内部的事务控制逻辑。务必确保工具使用的连接在初始化时显式执行了SET autocommit=0。
这些配置项通常不会写在工具的执行命令里，初期也不会直接报错。但它们就像暗礁，往往在某个数据分片（chunk）拷贝完成后突然引发“unexpected EOF”之类的静默失败，让人措手不及。
