按用户分片后，按订单号查询却不知道去哪一库。分片键选择决定后续访问成本。
本文使用关系数据库的逻辑分片演算与路由伪代码。分片把单点容量问题变成数据路由与跨分片协调问题。先确定业务访问模式和事务边界，再决定是否值得承担新的复杂度。
1. 从现象推到机制
一个路由键能让高频访问落到单分片，却可能让其他查询需要广播。分片键还影响数据倾斜与跨实体事务。订单号若不含路由信息，可以维护可靠索引映射，但映射本身又成为需要一致维护的状态。
图中的四个节点分别表示访问模式、分片键、路由规则、迁移路径。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先列前五类查询，分别标出是否携带分片键。用一份匿名订单清单模拟分布，不先引入复杂中间件。
1
2
3
4
route = hash(owner_id) % shard_count
queries_with_owner -> single shard
queries_by_order_only -> route index or controlled fan-out
record routing version for migration
在演示数据中保存分片键、路由版本与业务身份。先验证查询能否定位，再检查扩容、聚合和故障恢复；路由函数能运行不表示全生命周期已经正确。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 主要查询携带用户编号 | 可以直接定位目标分片 |
| 仅有订单号但无映射 | 可能不得不广播查询 |
| 少数用户数据特别大 | 均匀编号不保证负载均匀 |
对照 1：主要查询携带用户编号
可以直接定位目标分片。观察时记录查询参数与路由结果。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：仅有订单号但无映射
可能不得不广播查询。观察时记录是否存在稳定路由依据。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：少数用户数据特别大
均匀编号不保证负载均匀。观察时记录按业务键统计的数据与流量。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
分片数量变化会改变取模结果。扩容必须设计迁移、双读或路由版本，不能简单改一个除数就认为旧数据跟着移动。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“少数用户数据特别大”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
