MySQL分库分表后怎么迁移数据
我已经有一套单库单表的 MySQL 业务，现在准备做分库分表。面对历史数据量很大、业务还在持续写入的情况，怎样才能在尽量不影响线上访问的前提下，把老数据迁移到新库新表里？
可以通过“全量迁移 + 增量同步 + 切流验证”的方式平滑迁移
可行的做法是先把历史数据按分片规则进行全量导入，再借助 binlog、CDC 或双写机制同步迁移期间产生的增量数据。迁移过程中需要保证新旧架构的数据映射规则一致，避免出现路由错误。完成数据同步后，可以通过灰度切流的方式逐步把读写流量导向新库新表，并结合对账、抽样校验、延迟监控来确认数据一致性。这样既能减少停机时间，也能降低迁移风险。
在迁移过程中，业务还在持续产生订单、用户、日志等数据。如果一边迁移一边写入，怎样保证数据不会漏迁、重复迁移，或者在新旧库之间出现脏数据？
需要通过幂等写入、增量校验和一致性控制来降低风险
为避免数据丢失或重复写入，迁移方案应尽量支持幂等处理，例如使用唯一键、去重标识或任务状态表控制重复执行。增量同步阶段要确保源库变更能被完整捕获，并在目标库侧进行顺序消费与重放校验。对于写入链路，可以采用双写加比对，或在短时间内冻结部分敏感操作，减少并发冲突。迁移结束后，建议进行全量对账、关键字段校验和抽样回放，确认两边数据完全一致。
如果现在开始迁移，分片键应该按用户ID、订单ID还是时间来设计？我担心一旦规则选错，后面数据搬迁、查询路由和扩容都会很麻烦，应该怎么判断？
分片规则要优先匹配业务访问模式和数据增长特征
分片键的选择应围绕核心查询条件、写入热点和后续扩展能力来定。如果业务主要按用户维度查询，用户ID通常更适合作为分片键；如果订单类业务更关注用户归属和订单生命周期，也可以考虑组合分片策略。应尽量避免使用会频繁变更、分布极不均匀或无法支撑高频查询的字段。迁移前可以先通过历史数据分析评估数据倾斜、热点分布和跨库查询比例，再确定分片规则。设计得越贴近真实业务模式，后续迁移成本和返工概率就越低。
数据库拆成多个库表以后，原来依赖单库单表的 SQL、分页查询、关联查询、事务处理还能直接用吗？应用层一般需要做哪些调整，才能适配新的架构？
大多数场景下都需要调整路由、查询方式和事务设计
分库分表之后，原有 SQL 往往不能直接沿用，尤其是跨分片 Join、全局排序、深分页和大范围聚合查询，通常需要改造。应用层一般要引入分片路由能力，让查询能根据分片键准确落到目标库表；对于复杂统计类需求，可能需要走中间层汇总或离线计算。事务方面，原先依赖单库事务的逻辑也可能需要拆解，改成本地事务、最终一致性或消息驱动方案。代码改造时最好同步增加路由测试和回归测试，避免迁移后出现隐性查询错误。