本文目录导读：
- 第一阶段：双写（核心基石）
- 第二阶段：历史数据迁移（全量迁移）
- 第三阶段：数据校验（最关键防线）
- 第四阶段：灰度切换（流量渐进）
- 第五阶段：回滚预案与清理（最终闭环）
- 关键难点及应对策略（PHP特别提示）
- 简易流程图（示意）
- 总结建议
PHP分库分表的平滑过渡是一个系统工程，核心目标是在不停机或极小影响的前提下,完成数据迁移和架构升级。
整个过渡方案通常分为双写、历史数据迁移、核对校验、灰度切换、回滚预案五个阶段,下面是一个标准的实施路线图：
第一阶段：双写（核心基石）
在分库分表中间件（如ShardingSphere、MyCat或自研路由）就绪后，开始对增量数据进行双写。
- 代码改造：修改DAO层，在写入老库（单库）的同时，异步写入新库（分片）。
- 异步处理：建议通过消息队列（MQ）或本地binlog监听（如Canal）进行异步双写,避免影响主业务请求耗时。
- 幂等保障：新库写入必须带唯一键或业务主键,确保消息重试时不会插入重复数据。
第二阶段：历史数据迁移（全量迁移）
针对存量数据,需要编写迁移脚本或使用工具。
- 数据扫描：按老库主键ID（或时间）分批扫描（例如每次取500条）。
- 路由计算：将老库主键传入分片算法,计算出目标分片表。
- 批量插入：将数据批量写入对应的新分片表中。
- 去重处理：迁移时使用
INSERT IGNORE或ON DUPLICATE KEY UPDATE,防止双写阶段新数据已存在时导致冲突。
第三阶段：数据校验（最关键防线）
不能迁移完就算结束,必须进行数据一致性校验。
- 比对策略：按主键或唯一索引，对比老库和新分片的字段值（MD5校验）。
- 补偿机制：发现不一致的数据，以老库为准，重跑该条数据的迁移任务（增量补偿）。
- 循环检测：在双写持续期间，定期（如每10分钟）跑一次增量校验任务，直到连续多次校验通过（例如连续3次差异为0）。
第四阶段：灰度切换（流量渐进）
当数据完全一致，且新库读写稳定后,开始切换流量。
- 开关控制：在配置中心（如Apollo、Nacos）或Redis中设置
switch开关。 - 灰度比例：
- 先切 1% 的流量（例如按用户ID最后一位尾号0的用户）走新库。
- 观察日志、错误率、慢查询。
- 逐步提升到 10% -> 50% -> 100%。
- 读多写少策略：如果读写分离，先切读流量,再切写流量。
第五阶段：回滚预案与清理（最终闭环）
虽说是平滑过渡，但必须准备“后悔药”。
- 窗口期：灰度切换期间（如切换后48小时内），保留老库数据，且老库继续接受双写（即如果新库写失败，回滚到老库）。
- 永久回滚：如果新库出现严重故障，将开关拨回“老库”，停止新库读取,老库数据仍然完整。
- 数据收敛：确认稳定运行后，停止双写代码,下线老库或改为备份归档。
关键难点及应对策略（PHP特别提示）
在PHP生态中，由于通常没有像Java那样重量级的ORM框架,实施时需注意以下几点：
- 连接池问题：PHP是短生命周期脚本，每次请求都会重新建立数据库连接，在过渡期，避免在单次请求中同时连接大量老库和新库分片（会导致连接数爆炸），建议使用
Swoole常驻内存或合理的连接池。 - 路由层抽象：必须把SQL路由逻辑封装在中间件或独立的类库中，绝对不能散落在各个控制器里，推荐使用
ShardingSphere-Proxy（SQL解析代理），PHP直接连Proxy，代码改动量最小。 - 分布式ID生成：分库分表后，老库的
AUTO_INCREMENT失效，必须改用雪花算法（Snowflake）或号段模式生成全局唯一ID，否则双写时新旧ID对不上,迁移校验会失败。
简易流程图（示意）
[老单体库] <--- 双写(写老库+写MQ) --- [新分片集群]
^ ^
| |
+----(定时任务/脚本) 全量迁移 + 校验 -----+
|
[流量开关] -- 1% --> 新库
|
+-- 100% --> 新库 (老库留作备份或下线)
总结建议
对于PHP项目，最稳妥的“无缝”方案是引入数据库代理层（Proxy）：
- 业务代码依然连接一个虚拟的“逻辑库”地址（即Proxy）。
- Proxy内部根据配置,规则化地将请求路由到老库或新分片。
- 这样，PHP代码本身完全不需要改动，只需要修改数据库连接配置（指向Proxy）,大大降低了代码侵入风险。
这套方案中，数据校验阶段耗时最长，建议用PHP的常驻内存脚本（Swoole）来做批量比对,性能会比传统FPM模式高很多。
