MySQL Percona Toolkit在线Schema变更指南

pt-online-schema-change 到底在做什么？

先澄清一个常见的误区：pt-online-schema-change 的用途不是“加速” ALTER TABLE，它本身不依赖原生 DDL 路径。因此，讨论它“快不快”没有实际意义——它的核心价值在于解决“能否在线执行”的问题。

如果你使用的是 MySQL 8.0.12 及以上版本，仅需加一列时，直接执行 ALTER TABLE ... ADD COLUMN ... ALGORITHM=INSTANT 即可，更轻量、更简单。但一旦涉及 DROP INDEX、MODIFY COLUMN、CHANGE COLUMN、主键变更或分区调整，pt-online-schema-change 仍是目前最可靠的在线 schema 变更工具。

为什么不能直接使用 ALTER TABLE？

在 MySQL 5.7 及更早版本中，对千万级大表执行 ALTER TABLE，几乎必然触发全表拷贝加排他锁。INSERT、UPDATE、DELETE 全部被阻塞，即使 SELECT 在 RR 隔离级别下也可能被卡住。即便 MySQL 8.0 的 Online DDL 提供了改进，但并非万能——除了 ADD COLUMN 支持无锁操作，其他大部分操作要么重建表，要么持有元数据锁。

常见的报错场景包括：

• Lock wait timeout exceeded，应用写入直接失败
• Threads_running 持续飙升，innodb_row_lock_time 暴涨
• 主从延迟突然拉大，甚至复制中断（DDL 在从库回放缓慢）

执行前必须确认的三件事

跳过任何一项，都可能导致事后难以处理的问题——比如失败后无法回滚、主从不一致、或触发器堆积导致性能下降：

• 目标表必须是 InnoDB 引擎。MyISAM 不支持事务和行级锁，pt-online-schema-change 无法兼容
• 表上不能存在已定义的触发器。工具会在原表创建三个触发器，已有触发器会直接报错退出
• 用户权限需完整：CREATE、DROP、ALTER、INSERT、DELETE、SELECT、UPDATE、PROCESS、REPLICATION SLAVE、TRIGGER，缺一不可

关键参数如何配置才能避免故障？

默认值在生产环境中容易引发问题，尤其在负载高、从库延迟波动大的场景下。以下参数若配置错误，可能导致操作中断或数据异常：

• --chunk-size=1000：默认值偏保守，大表建议设为 5000~10000，能减少触发器调用频次。但不要超过 100000，否则单次更新耗时过长，容易触发 --max-lag 中断
• --max-lag=3s：默认 1s 过于敏感，建议设为 3s 或 5s。如果从库长期延迟超过 5s，先排查慢 SQL、IO 或网络问题，再运行 pt-osc
• --critical-load="Threads_running=256"：当 SHOW STATUS LIKE 'Threads_running' 超过该值时，工具会立即退出。建议设为当前业务峰值的 1.2 倍，避免随意填写 512
• --check-interval=5：每 5 秒检查一次延迟和负载。间隔太短增加开销，太长则响应滞后，5~10 秒较为平衡
• --no-check-alter：慎用！仅当确认 --alter 语法合法且兼容目标 MySQL 版本时，才可跳过校验。否则可能中途失败，留下残留触发器和 _表名_new 表

外键和字符集容易被忽略的坑

这两类问题不会直接报错，但一旦出现，排查起来非常困难：

• 含外键的表必须显式指定 --alter-foreign-keys-method，否则工具拒绝执行。推荐使用 rebuild_constraints（重建约束），避免使用 drop_swap（风险较高）
• --charset=utf8 必须显式传入，尤其在阿里云等托管环境中，否则中文字段可能乱码。注意，这里不是 utf8mb4，工具内部对 utf8mb4 支持不稳定。建议统一使用 utf8，或升级到 pt-online-schema-change 3.5.4+，配合 --set-vars="collation_connection=utf8mb4_unicode_ci"
• --alter 中不能出现 RENAME，也不能通过“删列+加列”来模拟重命名——数据不会迁移过去。非空列必须带 DEFAULT，否则操作失败

最麻烦的其实是事后清理：如果手动中断或操作失败，需要自行删除 _表名_new 表、_表名_old 表，以及那三个触发器——工具不会自动处理。这一点在实际操作中务必提前规划清楚。