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 依然是最可靠的在线方案。
为什么不能直接用 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 表以及那三个触发器——工具不会帮你善后。这一点在实际操作中务必提前计划清楚。
