pt-online-schema-change 并非加速 ALTER TABLE，而是绕过原生 DDL 实现在线变更；仅 MySQL 8.0.12+ 的 ADD COLUMN 可用 INSTANT 算法，其余如 DROP INDEX、MODIFY COLUMN 等仍需该工具。
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 表，以及那三个触发器——工具不会帮你善后。
