pt-online-schema-change 并非真正无锁，而是通过拆分DDL为小事务、用触发器同步主表与影子表增量变更，保障主表持续可读写；需满足ROW格式、无外键等条件，否则易卡住或数据不一致。
pt-online-schema-change 为什么能“无锁”
它不是真不加锁，而是把 DDL 拆成小事务，在主表和影子表之间用触发器同步增量变更，让 ALTER TABLE 对业务查询几乎不可见。关键在「在线」——主表始终可读写，只是写入会多一次触发器开销。
常见错误现象：pt-online-schema-change 卡住不动、CPU 突增、从库延迟飙升、触发器残留导致后续写入失败。
- 必须确保主库 binlog_format = ROW，否则触发器无法正确捕获变更
- 目标表不能有外键（
--alter-foreign-keys-method=auto可绕过，但风险高） - 如果表有
ON DELETE CASCADE或复杂触发器，pt-osc会拒绝执行，得先清理 - 默认每批次拷贝 1000 行，遇到大字段或慢索引时容易超时，需调
--chunk-size
怎么安全启动一次变更
别直接跑 pt-online-schema-change，先做三件事：查负载、试干跑、设超时。
使用场景：加字段、改字段类型（非安全转换除外）、删索引、加索引（尤其是唯一索引）。
- 用
SHOW PROCESSLIST和pt-query-digest看当前写入压力，避开高峰期 - 加
--dry-run --execute先模拟建影子表、检查触发器、验证语法，不真正拷数据 - 强制设置
--max-load="Threads_running=25"防止拖垮实例；加--critical-load="Threads_running=50"到阈值自动退出 - 加上
--check-interval=5和--max-lag=1，避免从库延迟过大时继续推进
哪些 alter 操作其实不安全
pt-online-schema-change 能扛住大部分 DDL，但有些操作它没法兜底，强行上会出数据不一致。
参数差异：--alter 后的语句必须是单条 ALTER TABLE ... 语法，不能带分号或多个逗号分隔命令。
-
MODIFY COLUMN改类型且可能丢精度（如VARCHAR(255)→VARCHAR(50)）：工具不会校验截断，得自己确认数据 -
DROP PRIMARY KEY：影子表会失去主键，同步触发器失效，直接报错退出 -
CHANGE COLUMN重命名 + 改类型：可以，但新列名必须在影子表中存在且类型兼容，否则拷贝阶段崩在INSERT INTO ... SELECT - 对
JSON字段加虚拟列并建索引：MySQL 5.7+ 支持，但pt-osc5.7 版本有 bug，建议升到 3.7.0+
执行完一定要手动验证
工具删影子表、删触发器、rename 成功，不代表数据就对了。线上出过太多“结构变了、数据丢了”的 case。
性能影响：拷贝阶段 IO 和网络压力明显，尤其跨机房环境；触发器带来的额外写入会让 QPS 小幅下降（通常
- 用
SELECT COUNT(*)对比主表和新表行数（注意事务隔离级别，建议 RR 下快照一致性） - 抽样几条最新写入的记录，用
SELECT * FROM tbl WHERE id IN (x,y,z)检查字段值、NULL 性、时间戳是否一致 - 查
information_schema.TRIGGERS确认触发器已清空；查SHOW CREATE TABLE确认索引、字符集、存储引擎全量生效 - 如果用了
--swap-tables（默认行为），rename 完后立刻看SHOW TABLE STATUS的Create_time是否更新
最容易被忽略的是从库延迟观测窗口——主库 rename 完，从库可能还在回放老表的触发器日志，得盯 2~3 分钟 Seconds_Behind_Master 归零再收工。
