ShardingSphere-Proxy是独立代理进程，兼容MySQL协议，业务零代码改动即可实现分库分表迁移；需配置Cluster模式与orchestration（如ZooKeeper），显式执行CREATE MIGRATION（存量）和START MIGRATION + streaming=true（增量），并严格校验GTID或binlog位点对齐后方可切流。
ShardingSphere-Proxy 是迁移入口，不是 JDBC
微服务拆库分表时，如果还在应用层用 ShardingSphere-JDBC 做迁移，会卡在改造成本和双写一致性上：每个服务都要改数据源、加双写逻辑、处理主键冲突。而 ShardingSphere-Proxy 是独立进程，兼容 MySQL 协议，所有业务连它就像连原库一样——你只需把流量切到 Proxy，后续迁移动作全在 Proxy 层控制，业务零代码改动。
关键点在于部署拓扑：
– 旧库保持可读写（作为源）
– 新分片集群（按规则建好多个物理库/表）作为目标
– ShardingSphere-Proxy 启动后配置 mode: Cluster + orchestration（对接 ZooKeeper 或 etcd），才能支撑迁移任务持久化与多节点协同
常见错误现象：
– Proxy 启动报 Cannot find driver class：缺 MySQL 驱动 JAR，必须手动拷贝到 ext-lib/ 目录
– 迁移任务提交后状态一直是 PREPARING：没配 orchestration，或注册中心连不上
– 迁移中 Proxy OOM：默认堆内存 512MB 不够，需调大 JVM_OPTS="-Xms2g -Xmx2g"
存量 + 增量同步必须分开配置，不能只靠 auto-start
ShardingSphere-Proxy 的 dist-sql 迁移命令（如 CREATE MIGRATION）默认只触发存量拉取，不自动开启 binlog 增量捕获。如果你跳过这步，切流后新写入的数据就直接丢在旧库，新分片集群永远追不上。
实操必须显式执行两步：
– 存量迁移：CREATE MIGRATION job_01 FROM SOURCE (TYPE=MySQL, HOST='old_host', PORT=3306, ...) TO TARGET (...)
– 增量同步：START MIGRATION job_01 后，立刻补一句 ALTER MIGRATION job_01 CONFIGURATION (streaming=true)
注意参数差异：
– streaming=true 才启用 binlog 订阅，否则只跑完存量就停
– checkpoint 位点由 Proxy 自动从旧库 SHOW MASTER STATUS 拿，但要求旧库 binlog_format=ROW 且 binlog_row_image=FULL
– 若旧库是 RDS（如阿里云），需确认已开通「DTS 权限」或「binlog 开放」，否则 Proxy 无法连接 binlog
切流前必须验证 GTID 或 binlog position 对齐
很多团队切流时只查 SELECT COUNT(*)，发现新旧库行数一致就认为 OK —— 这完全不可靠。实际可能漏了部分事务（比如被过滤的 DDL、XA 回滚事务），或新库因分片路由错写到其他表。
真正有效的验证方式只有两种：
– 如果旧库开了 gtid_mode=ON：对比新分片集群中各分片的 SELECT @@global.gtid_executed 和旧库的值是否包含关系（用 GTID_SUBSET(gtid_set1, gtid_set2) 函数）
– 如果没开 GTID：用 SHOW SLAVE STATUS\G 查 Master_Host（即旧库）的 Exec_Master_Log_Pos，再进每个分片查 SELECT MASTER_POS_WAIT('mysql-bin.000001', 123456789) 是否返回非负数
容易踩的坑：
– 分片集群里某张子表没数据，不代表迁移失败，可能是该分片键范围无记录；要逐个分片查 gtid_executed，不能只看总行数
– Proxy 的迁移任务状态显示 RUNNING，不代表增量已追平；得查 SELECT * FROM proxy_backend_migration_status（内部表）确认 progress 列是否为 100%
回滚不是删 Proxy 配置，而是冻结 + 反向同步
切流后发现问题想回滚，别急着停 Proxy 或删分片配置。此时旧库可能已有新写入，直接切回会导致这部分数据丢失。正确做法是：先用 PAUSE MIGRATION job_01 冻结同步，再启动反向通道。
ShardingSphere 本身不提供反向迁移命令，但你可以复用同一套 Proxy 实例：
– 在 Proxy 配置中新增一个反向数据源，指向新分片集群为 SOURCE，旧库为 TARGET
– 写一个轻量脚本，从各分片 SELECT * FROM t_order WHERE create_time > ?（用最后切流时间戳）导出，再按分片键重路由插入旧库
– 完成后，再把业务连接切回旧库地址
这个过程里最易被忽略的是主键冲突：新分片集群用了自增 ID，而旧库 ID 已存在。解决方法只有两个：
– 旧库提前设 auto_increment_offset 错开起始值
– 插入前加 INSERT IGNORE 或用 ON DUPLICATE KEY UPDATE 跳过重复
