pt-online-schema-change能避开元数据锁，因其新建空影子表、用触发器捕获增量变更、分块拷贝历史数据，全程不触发MySQL原生DDL的全表重建与MDL等待。
直接对 MySQL 5.7 大表执行 ALTER TABLE 几乎必然导致业务卡顿甚至超时，pt-online-schema-change 是目前最稳妥的替代方案——它不依赖 MySQL 原生 Online DDL 的支持范围，而是用影子表+触发器把锁拆成毫秒级小段。
为什么 pt-online-schema-change 能避开元数据锁
MySQL 5.7 对 ADD COLUMN、DROP COLUMN、MODIFY COLUMN 等操作仍会触发全表拷贝（即使标称 ALGORITHM=INPLACE），本质是重建聚簇索引+二级索引，期间持有 Waiting for table metadata lock。而 pt-online-schema-change 完全绕开这个路径：
- 新建空表
_t_new，只改结构，无数据，秒级完成 - 在原表上建
INSERT/UPDATE/DELETE三类触发器，捕获所有增量变更 - 按主键分块（默认每批
--chunk-size=1000行）拷贝历史数据，每次只锁几行 - 最后原子
RENAME，耗时通常
整个过程原表始终可读写，SHOW PROCESSLIST 里看不到长时间 Waiting for table metadata lock。
执行前必须验证的 4 个硬性条件
pt-online-schema-change 不是“开箱即用”，漏掉任一条件都会失败或引发数据不一致：
- 原表必须有主键或唯一非空索引（否则无法分 chunk 拷贝，会报错
Cannot chunk table `db`.`t`: no primary key or unique not-null index - 原表不能已有任何触发器（
pt-osc会拒绝执行并提示Triggers exist on the table） - 操作用户需显式授予
TRIGGER、REPLICATION SLAVE、PROCESS权限（仅SELECT/INSERT/UPDATE/DELETE不够） - 若表被外键引用，必须加
--alter-foreign-keys-method=auto或rebuild_constraints，否则RENAME阶段会因外键约束失败
关键参数怎么调才不拖垮线上库
默认参数适合测试环境，生产大表必须调整，否则可能拉高 Threads_running 导致连接池雪崩：
-
--chunk-time=0.5：控制每批拷贝耗时上限（秒），值越小对 IO/CPU 冲击越小，但总耗时变长；10GB 表建议设为0.3～0.5 -
--max-load="Threads_running=25"：当SHOW STATUS LIKE 'Threads_running'>25 时自动暂停，避免压垮数据库 -
--check-interval=5：每 5 秒检查一次负载，配合--max-load使用 -
--critical-load="Threads_running=50"：超过该阈值直接退出，防止 DB 彻底卡死
别碰 --chunk-size —— 它由 --chunk-time 动态反推，手动设死容易导致单次锁行过久。
执行流程中两个最容易被忽略的坑
很多人跑通了 --dry-run 就以为万事大吉，实际在线上出问题的点往往藏在细节里：
-
--dry-run成功 ≠--execute安全：它只校验语法和权限，不校验长事务。如果执行时原表上有未提交的长事务，pt-osc会卡在等待 MDL，现象是进程僵住、日志停更；务必先KILL掉SHOW PROCESSLIST里State: Waiting for table metadata lock的线程 - 执行中断后残留资源必须手动清理：
_t_new表、_t_old表、3 个触发器；否则下次执行会因对象已存在而失败，且触发器持续消耗性能
真正安全的上线节奏是：--dry-run → 清理长事务 → --execute → 执行中盯 Threads_running 和慢查 → 完成后立刻 DROP TABLE IF EXISTS _t_old 并 SHOW TRIGGERS 确认触发器已删。
