PHP分库分表怎么平滑过渡

本文目录导读：

1. 第一阶段：双写（核心基石）
2. 第二阶段：历史数据迁移（全量迁移）
3. 第三阶段：数据校验（最关键防线）
4. 第四阶段：灰度切换（流量渐进）
5. 第五阶段：回滚预案与清理（最终闭环）
6. 关键难点及应对策略（PHP特别提示）
7. 简易流程图（示意）
8. 总结建议

PHP分库分表的平滑过渡是一个系统工程，核心目标是在不停机或极小影响的前提下,完成数据迁移和架构升级。

整个过渡方案通常分为双写、历史数据迁移、核对校验、灰度切换、回滚预案五个阶段,下面是一个标准的实施路线图：

---

第一阶段：双写（核心基石）

在分库分表中间件（如ShardingSphere、MyCat或自研路由）就绪后，开始对增量数据进行双写。

1. 代码改造：修改DAO层，在写入老库（单库）的同时，异步写入新库（分片）。
2. 异步处理：建议通过消息队列（MQ）或本地binlog监听（如Canal）进行异步双写,避免影响主业务请求耗时。
3. 幂等保障：新库写入必须带唯一键或业务主键,确保消息重试时不会插入重复数据。

---

第二阶段：历史数据迁移（全量迁移）

针对存量数据,需要编写迁移脚本或使用工具。

1. 数据扫描：按老库主键ID（或时间）分批扫描（例如每次取500条）。
2. 路由计算：将老库主键传入分片算法,计算出目标分片表。
3. 批量插入：将数据批量写入对应的新分片表中。
4. 去重处理：迁移时使用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE,防止双写阶段新数据已存在时导致冲突。

---

第三阶段：数据校验（最关键防线）

不能迁移完就算结束,必须进行数据一致性校验。

1. 比对策略：按主键或唯一索引，对比老库和新分片的字段值（MD5校验）。
2. 补偿机制：发现不一致的数据，以老库为准，重跑该条数据的迁移任务（增量补偿）。
3. 循环检测：在双写持续期间，定期（如每10分钟）跑一次增量校验任务，直到连续多次校验通过（例如连续3次差异为0）。

---

第四阶段：灰度切换（流量渐进）

当数据完全一致，且新库读写稳定后,开始切换流量。

1. 开关控制：在配置中心（如Apollo、Nacos）或Redis中设置switch开关。
2. 灰度比例：
   • 先切 1% 的流量（例如按用户ID最后一位尾号0的用户）走新库。
   • 观察日志、错误率、慢查询。
   • 逐步提升到 10% -> 50% -> 100%。
3. 读多写少策略：如果读写分离，先切读流量,再切写流量。

---

第五阶段：回滚预案与清理（最终闭环）

虽说是平滑过渡，但必须准备“后悔药”。

1. 窗口期：灰度切换期间（如切换后48小时内），保留老库数据，且老库继续接受双写（即如果新库写失败，回滚到老库）。
2. 永久回滚：如果新库出现严重故障，将开关拨回“老库”，停止新库读取,老库数据仍然完整。
3. 数据收敛：确认稳定运行后，停止双写代码,下线老库或改为备份归档。

---

关键难点及应对策略（PHP特别提示）

在PHP生态中，由于通常没有像Java那样重量级的ORM框架,实施时需注意以下几点：

1. 连接池问题：PHP是短生命周期脚本，每次请求都会重新建立数据库连接，在过渡期，避免在单次请求中同时连接大量老库和新库分片（会导致连接数爆炸），建议使用 Swoole 常驻内存或合理的连接池。
2. 路由层抽象：必须把SQL路由逻辑封装在中间件或独立的类库中，绝对不能散落在各个控制器里，推荐使用 ShardingSphere-Proxy（SQL解析代理），PHP直接连Proxy，代码改动量最小。
3. 分布式ID生成：分库分表后，老库的 AUTO_INCREMENT 失效，必须改用雪花算法（Snowflake）或号段模式生成全局唯一ID，否则双写时新旧ID对不上,迁移校验会失败。

---

简易流程图（示意）

[老单体库] <--- 双写(写老库+写MQ) --- [新分片集群]
    ^                                      ^
    |                                      |
    +----(定时任务/脚本) 全量迁移 + 校验 -----+
    |
[流量开关] -- 1% --> 新库
    |                  
    +-- 100% --> 新库 (老库留作备份或下线)

---

总结建议

对于PHP项目，最稳妥的“无缝”方案是引入数据库代理层（Proxy）：

• 业务代码依然连接一个虚拟的“逻辑库”地址（即Proxy）。
• Proxy内部根据配置,规则化地将请求路由到老库或新分片。
• 这样，PHP代码本身完全不需要改动，只需要修改数据库连接配置（指向Proxy）,大大降低了代码侵入风险。

这套方案中，数据校验阶段耗时最长，建议用PHP的常驻内存脚本（Swoole）来做批量比对,性能会比传统FPM模式高很多。