如何利用MySQL的Percona Toolkit实施在线Schema变更？

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 表，以及那三个触发器——工具不会帮你善后。