## pt-online-schema-change：不是语法糖，是唯一能走的“务实主义”路径 先说结论：**`pt-online-schema-change` 从来不是“ALTER TABLE 的更好写法”，而是在原生 DDL 会把业务锁死的时候，唯一还能继续推进的路径。** MySQL 对大表执行 `ALTER TABLE` 时，多数结构变更——比如改字段类型、删列、加唯一索引、调整字符集——在 5.7 及更早版本中，基本都是 `ALGORITHM=COPY` 模式。10GB 的表，跑个几十分钟并不夸张，期间所有写入操作都得排队等着 `Waiting for table metadata lock`，甚至 `SELECT` 在可重复读隔离级别下都可能被阻塞。你能想象业务方在这几十分钟里是什么感受吗？ 即使到了 MySQL 8.0.12+ 支持 `ALGORITHM=INSTANT`，适用范围也很有限：只能对新增一个没有默认值、非 `NOT NULL` 的列生效。其他操作呢？还是得乖乖拷贝全表。 所以，`pt-online-schema-change` 真正的价值，不在语法层面，而在于**把“一次长锁”拆解成“无数次毫秒级的短锁”**。它不走 MySQL 原生的 DDL 流程，而是绕过来干。具体怎么绕的？  **第一步：新建影子表**。一张空表 `_t_new`，秒级完成，只改元数据。 **第二步：在原表上建触发器**。`INSERT`、`UPDATE`、`DELETE` 三类触发器全部到位，覆盖所有增量变更。 **第三步：分块拷贝历史数据**。按照主键分批拷贝，每次只锁几行，不会锁住整张表。 **第四步：最后一步 `RENAME TABLE`**，原子替换，微秒级完成，业务侧几乎无感知。 全程你在 `SHOW PROCESSLIST` 里看不到长时间挂着的 `Waiting for table metadata lock`，原表始终可读可写。这才是它的核心魅力——**把锁的粒度做到极致细，细到几乎不影响正常业务。** ### 哪些场景必须用 pt-osc，别被“MySQL 8.0 支持 Online DDL”的噱头忽悠了 MySQL 8.0 的 Online DDL 确实进步不小，但以下这些操作，它依然要全表拷贝，或者无法安全执行： - **`MODIFY COLUMN` 改字段类型**：比如 `VARCHAR(100)` 改成 `VARCHAR(500)`，如果涉及到字节编码的变化（比如从 latin1 到 utf8mb4），MySQL 不吃这套，依然全表拷贝。 - **删除列（`DROP COLUMN`）**：听起来简单，但实际操作也是全表搬砖。 - **添加唯一索引（`ADD UNIQUE INDEX`）**：需要扫描整个表做唯一性校验，没得商量。 - **修改字符集或排序规则**（比如 `CONVERT TO CHARACTER SET utf8mb4`）：本质上是从头建表。 - **表上有长事务未提交**：这时候你发一个 `ALTER`，它会一直等着那个事务释放 MDL，哪怕那个事务只是跑了一个没 `COMMIT` 的 `SELECT`。结果就是，你的 `ALTER` 挂在那里，业务也挂在那里。 这些场景，才是 `pt-online-schema-change` 真正派上用场的地方。 ### 不检查就跑 --execute，等于把数据库交给运气 很多人拿到 `pt-online-schema-change`，直接就 `--execute` 跑起来了。这是典型的生产事故导火索。 线上大表必须预检并调参，核心检查项如下： - **原表必须有主键或唯一非空索引**，否则它会直接报错：`Cannot chunk table 'db.t': no primary key or unique not-null index`。 - **原表不能已有任何触发器**，`Triggers exist on the table`，也是直接退出的。 - **操作用户的权限要够**：`TRIGGER`、`REPLICATION SLA VE`、`PROCESS` 一个不能少。光有 `SELECT`、`INSERT`、`UPDATE`、`DELETE` 是不够的。 - **先跑 `--dry-run`**。这个参数会模拟整个过程：建影子表、验权限、试触发器，但不拷数据，也不改名。跑完之后确认没问题，再上 `--execute`。 - **资源保护参数必须设置**：比如 `--max-load="Threads_running=25"`（超出这个值就暂停），`--critical-load="Threads_running=50"`（超出就退出），`--max-lag=1`（从库延迟超过1秒就停，避免影响同步）。 不设这些参数，等于在高峰期硬冲，数据库扛不住，业务就跟着遭罪。 ### 最容易忽略的两个细节，务必留个心眼 **第一个坑：外键。** 如果这张表被其他表引用了，不加 `--alter-foreign-keys-method=auto` 或 `rebuild_constraints`，在 `RENAME` 阶段会直接失败。不要想当然地认为“我的表没有外键”，很可能其他表的外键指向了它。 **第二个坑：`--chunk-size` 手动设死。** 很多人喜欢写死一个行数，比如 10000。但真正正确做法是用 `--chunk-time=0.5` 让工具动态反推每批的大小。硬设固定行数，反而容易导致单次锁行时间过长，拖慢主表写入。 **核心原则：控制每批耗时（`--chunk-time`），而不是行数。** 这个参数才是真正决定是否影响业务的关键。 > 题外话：不少人问过我，有没有更简单的方案？比如用 MySQL 8.0 的 `ALGORITHM=INSTANT` 就够了？答案很明确：**不能全信。** 尤其是在生产环境，面对那些没法预判的长事务、外键引用、字符集变更，`pt-online-schema-change` 才是真正经得起考验的兜底方案。