pt-osc是mysql 5.7大表ddl刚需工具，需主键/唯一索引、无现有触发器、binlog_format非statement、外键须指定处理方法；--dry-run不校验同步能力，--execute才全量执行；须调优--chunk-time、--max-lag等参数并完成drop _old表等收尾。
MySQL 5.7 原生支持部分 Online DDL，但遇到 ADD COLUMN（非末尾）、MODIFY COLUMN、DROP COLUMN 或含外键/无主键的大表时，仍会触发 rebuild-table 流程，导致长时间锁表或主从延迟飙升。这时候 pt-online-schema-change（简称 pt-osc）不是“可选”，而是生产环境的刚需——它绕过 MySQL 内核限制，靠影子表 + 触发器实现真正读写不阻塞。
必须满足的硬性前提条件
pt-osc 不是万能胶，它对表结构和环境有明确约束，不满足直接报错退出：
-
表必须有主键或唯一非空索引，否则无法分 chunk 拷贝数据，会卡在Cannot chunk the original table错误 -
表不能已有任何触发器，因为 pt-osc 要自己创建INSERT/UPDATE/DELETE三类 AFTER 触发器来捕获变更，冲突即失败 -
MySQL 5.7 实例需关闭 binlog_format = STATEMENT（推荐MIXED或ROW），否则触发器写 binlog 可能引发主从不一致 - 若表有外键，
--alter-foreign-keys-method必须显式指定（常用auto或rebuild_constraints），否则工具拒绝执行
--dry-run 和 --execute 的本质区别
这两个参数决定操作是否真正落地，但很多人误以为 --dry-run 是“安全预演”——其实它只建新表、改结构、不建触发器、不拷数据，**完全不验证触发器逻辑和同步能力**，极易掩盖真实风险：
-
--dry-run：仅做语法检查 + 新表创建 +ALTER TABLE执行，跳过所有数据迁移环节。适合快速确认--alter语句是否合法，但无法发现外键处理失败、字符集不匹配等运行时问题 -
--execute：完整走完全部流程（建触发器 → 分 chunk 拷贝 → 应用增量变更 → 原子 rename）。必须搭配--print使用，实时观察每一步输出，尤其关注Copying rows进度和Max lag报警 - 切忌跳过
--dry-run直接--execute；更忌只跑--dry-run就认为“没问题”——它连第一行数据都没碰过
关键参数避坑指南
默认参数在生产环境大概率翻车，以下几项必须按场景调整：
-
--chunk-time：控制每次拷贝数据的时间上限（秒），默认 0.5。高并发写入场景建议压到0.02~0.05，避免单次 chunk 持锁过久拖慢业务 -
--max-lag：监控从库延迟，单位秒，如--max-lag 2。一旦从库Seconds_Behind_Master > 2，pt-osc 自动暂停拷贝，防止雪崩。5.7 主从半同步下务必启用 -
--critical-load：防抖阀值，例如--critical-load "Threads_running:30"。若拷贝中SHOW GLOBAL STATUS LIKE 'Threads_running'突破 30，立即中止，避免拖垮实例 -
--set-vars：必须设innodb_lock_wait_timeout=1，否则触发器内更新失败可能卡死整个流程；同时加lock_wait_timeout=5防元数据锁争用 -
--alter中禁止出现RENAME TO，列重命名必须用CHANGE COLUMN old_col new_col type，且类型变更要兼容（如VARCHAR(50)→VARCHAR(100)可行，反向不行）
执行后最易被忽略的收尾动作
rename 完成不等于万事大吉，以下三点常被跳过，埋下故障隐患：
原表被重命名为 <code><table>_old，必须人工确认新表数据一致、业务无异常后，再手动 <code>DROP TABLE <table>_old。留着它会持续占用磁盘空间，且某些监控脚本可能误扫到 _old 表引发告警 <li><code>触发器虽被自动删除，但需 <code>SHOW TRIGGERS LIKE '<table>' 二次确认，防止残留触发器干扰后续 DDL <li><code>如果用了 <code>--alter-foreign-keys-method=auto，外键约束已重建，但需检查关联子表的FOREIGN_KEY_CHECKS是否为 ON，避免后续插入触发约束失败
