分库分表先选对分片键，再设计可回退的在线扩容

先判断分片方式是否符合主要访问路径

适用边界：先区分表分区、读写分离与水平分片

本文讨论把同一逻辑数据集按规则分布到多个可独立承载读写的分片。数据库内部表分区可以帮助裁剪扫描和管理历史数据，读写分离可以转移允许陈旧的查询，但它们都不自动分散主库写入；是否分片必须对应已经观测到的限制。

先保留一份相同数据与负载下的基线：关键路径吞吐与延迟、写入日志或磁盘压力、锁等待、连接、表与索引增长、备份恢复时间，以及高峰时首先饱和的资源。若问题来自缺失索引、一次请求重复查询、全表导出或失控重试，直接分片会把同一问题复制到更多节点。

PostgreSQL 官方文档说明分区裁剪取决于分区边界与查询条件，而不是索引本身；分区可以改善特定大表访问和维护，却仍可能位于同一数据库实例。采购或评审方案时应写清“单表分区”“只读副本”“逻辑拆库”和“跨节点分片”各自解决什么问题，避免用同一名词承诺不同能力。

• 以监控和压测证明单库限制及预计到达时间。
• 先评估索引、查询、归档、读写分离和业务拆分是否足够。
• 记录团队能否承担路由、迁移、备份、故障与多分片变更。

分片键要同时满足分布、查询局部性与长期稳定

分片键决定一条数据放在哪里，也决定查询能否直达目标分片。候选字段要同时检查基数、频率分布、增长方向、是否出现在主要请求中、是否会变更，以及能否让需要原子更新的数据放在一起。

MongoDB 官方资料指出，理想分片键既要让数据分布较均匀，也要支持常见查询；低基数、频率倾斜或常见查询不含分片键，会造成大块、负载不均或 scatter-gather。均匀不等于适合业务：纯哈希可以打散连续写入，却可能破坏按时间或地区范围读取；纯时间范围便于归档，却可能让最新范围成为持续写入热点。

用脱敏历史分布与未来增长假设评估候选键，而不是只看当前总行数。对租户键检查最大租户、单租户突增和租户合并拆分；对用户或订单键检查关联明细、支付、库存和售后是否需要跨分片。键值若可能改变，要定义搬迁语义和旧路由缓存失效；如果无法安全改变，应把它视为长期数据契约。

• 统计候选键的基数、最大频率、增长趋势和热点时段。
• 用真实查询样本计算可定向请求与多分片请求比例。
• 确认订单及其明细、审批或会话等需原子处理的数据能否共置。

把路由、标识、唯一性和跨分片操作写入业务契约

分片后，应用不能再假定一个本地自增值在全局唯一，也不能默认任意关联查询、唯一约束和事务都跨节点成立。路由层需要从请求上下文得到可信分片键，并让读写、任务、消息和运维工具使用同一版本规则。

为业务对象使用不会依赖单库序列冲突的稳定全局标识，同时明确手机号、外部单号或设备号等全局唯一字段由哪个权威入口认领。只在各分片建立唯一索引无法证明全局唯一；可以使用独立注册表、确定性路由或受控协调，但必须验收并发冲突、超时结果未知和故障恢复。日志、指标和审计保留业务标识、逻辑分片与物理目标，且不记录敏感凭据。

跨分片事务不是默认能力。优先调整业务边界，让必须一起成功的数据按同一键共置；确需跨分片时，明确采用的数据库能力、失败状态、幂等、补偿与人工对账，不能用“最终一致”掩盖金额、库存或权限长期不一致。AI 智能体、后台报表和运营搜索不得绕过路由直接扇出全库，应走受权的数据服务、索引或离线汇总。

• 统一 Web、小程序、APP、智能体工具、消费者与后台任务的路由契约。
• 为全局唯一、跨分片事务和聚合查询指定权威来源及失败语义。
• 路由版本、分片映射与对象位置可追踪，但不向客户端暴露物理拓扑。

在线迁移要经历复制、追平、校验、切流与可逆窗口

从单库到多分片或从旧分片到新分片时，目标是在业务持续运行期间建立可验证的新副本，再把读写入口按受控顺序切换。不要让应用长期自由双写两个目标；任何双写都要有固定顺序、失败记录和对账来源。

可执行流程通常包括：冻结表结构和路由契约；创建目标结构与索引；按稳定游标复制历史数据；持续捕获源端增量并监控延迟；比较行数、键范围、聚合值和抽样业务对象；先灰度影子读或可回退读流量；在增量追平且停止条件满足时切换写入；保留限定期限的反向同步或回切能力；最后停止旧写入并归档旧数据。每一步都要记录版本、断点和负责人。

Vitess 官方对 resharding 的说明包含从源分片复制到目标、追平复制、比较数据并切换流量；其当前切流工具也支持按流量类型切换及反向复制选项。这里引用的是迁移阶段的可验证思路，不代表任意数据库都自动具备相同行为。MongoDB 的在线 resharding 也有版本、资源、索引、唯一性与写阻塞等具体前提，因此实施必须按实际产品版本阅读限制，不能把厂商命令当作通用零停机保证。

• 为全量复制、增量追平、数据校验和切流分别设置暂停条件。
• 先切可回退的读取，再按业务单元灰度写入并观察增量与错误。
• 限定双轨期限；结束前证明旧目标只读、回切入口可用且责任清楚。

扩容与热点治理要在路由层预留下一次变化

第一次从一个库拆成多个库只是开始。业务增长、头部租户、时间热点和数据倾斜会改变负载，路由设计必须允许拆分或搬迁有限范围，而不是把节点数量写死在每个客户端和服务里。

持续观察每个逻辑分片的数据量、写入、读请求、存储与延迟，同时检查单个键或范围的集中度。平均分布可能掩盖某个热点分片已经饱和。发现热点后先判断是单个业务主体、单调写入、查询扇出还是后台任务造成，再选择细化键、拆分范围、隔离大租户、调整任务或重新分片；不能只增加空闲节点却不移动热点数据。

MongoDB 官方故障排查资料把低基数、频率倾斜和常见查询缺少分片键列为大块、不均衡与查询退化的来源，并建议根据原因细化或更换分片键。无论使用何种平台，都应在测试环境演练增加节点、迁移一个热点范围、路由缓存刷新和迁移中断恢复，记录新增容量真正接到多少业务流量。

• 按分片与热点键观察容量，不只看集群总平均。
• 演练增加、拆分、搬迁和下线分片，验证旧路由不会继续写入。
• 把下一次扩容的临时空间、网络、复制和运维窗口计入成本。

验收与风险：性能提升必须和数据正确性一起通过

验收固定代码、数据规模、请求组合和分片映射，对比分片前后的有效业务完成量、延迟、失败、资源与成本。还要覆盖热点键、跨分片查询、目标节点故障、路由配置错误、迁移暂停、切流回退和恢复后的再次追平。

数据验收不只比总行数。对订单、余额、库存、审批和会员权益按稳定业务键核对主记录、明细、状态历史、金额或数量汇总与关联完整性；对允许最终一致的汇总记录最大滞后与恢复证据。随机抽样只能作为补充，关键约束和异常集合需要全量规则检查。切流后继续监控旧库写入、未知路由、跨分片扇出和对账差异，达到观察期前不销毁回退所需数据。

主要风险包括错误键导致热点或大范围扇出、双写部分成功、全局唯一冲突、跨分片事务悬而未决、路由缓存不一致，以及迁移占用磁盘、网络和日志能力拖慢线上业务。报告应写明未覆盖的数据库版本限制、第三方组件、最大租户与增长假设；如果正确性、回滚或容量任何一项无法证明，应停止切流并明确为未完成，而不是只凭新节点可连接就验收。

• 关键业务对象、唯一约束与聚合金额通过规则化对账。
• 热点、故障、错误路由、迁移中断与回切均有演练记录。
• 报告包含分片边界、路由版本、容量结论、成本与下次复测条件。

需求讨论中的问题

关联服务与实施资料

下面的页面可继续核对相关技术边界、业务接入方式与项目交付条件。

• 慢 SQL 与索引优化指南：先排除查询与索引问题，避免把低效访问复制到每个分片。
• 数据库读写分离指南：比较只读副本与水平分片分别解决的读压力、写入和一致性问题。
• 旧系统历史数据迁移指南：继续核对全量、增量、切换、回退和业务对账的通用迁移边界。
• AI Agent 智能体开发：让智能体通过受权数据服务查询，避免无分片键扇出和跨租户访问。
• 小程序与 APP 一体化开发：让多端接口携带可信业务上下文，并由服务端统一完成分片路由。
• 软件项目启动资料包：整理数据规模、主查询、迁移窗口、验收样例与责任边界。