改分片键能减少跨分片路由，因其使常见查询满足复合分片键前缀匹配，让mongos精准路由到单分片；需按高频查询将必查字段置左，且字段顺序不可后续调整。
为什么改分片键能减少跨分片路由
跨分片路由（broadcast query）发生的核心原因是：查询条件里没带分片键，或者只带了复合分片键的一部分字段。mongos 没法确定数据在哪一个分片上，只能把请求发给所有分片，再合并结果。这不仅慢，还放大网络和 CPU 开销。改用更合理的复合分片键，本质是让常见查询都能命中「单分片寻址」路径——只要 find() 或 aggregate() 的 filter 里包含完整分片键（或前缀），mongos 就能直接路由到目标分片。
复合分片键必须满足“查询前缀匹配”原则
MongoDB 的复合分片键（如 {tenant_id: 1, device_id: "hashed"}）不是随便拼的，它遵循和复合索引一样的前缀规则：只有查询中包含最左连续字段，才能触发精准路由。比如：
- ✅ 有效路由：
{tenant_id: "t-123", device_id: "d-456"}（完整键） - ✅ 有效路由：
{tenant_id: "t-123"}（仅左前缀，范围分片下可路由到部分 chunk） - ❌ 广播查询：
{device_id: "d-456"}（跳过tenant_id，mongos 无法定位） - ❌ 广播查询：
{status: "online"}（完全无关字段）
所以，设计时得先梳理高频查询模式，把「必查字段」放在复合键最左侧。多租户系统通常选 tenant_id 打头；IoT 设备数据则优先保证 device_id 或 device_id + timestamp_month 组合可被大多数写入/查询覆盖。
改分片键不是 ALTER TABLE，要选对命令和时机
MongoDB 5.0+ 提供了两个关键命令，但它们用途完全不同，用错会导致数据不可路由或迁移卡死：
-
refineCollectionShardKey：只能往现有分片键「加后缀字段」，比如从{user_id: 1}扩展为{user_id: 1, region: 1}。不重建数据，快且安全，但不能删字段、不能改顺序、不能换哈希/范围类型。 -
reshardCollection：真正意义上的重分片，可彻底更换分片键（如从{created_at: 1}改成{user_id: "hashed"}）。会触发全量数据重分布，期间写入可能延迟，且要求集合有足够空闲空间容纳临时副本。
注意：reshardCollection 不支持在 timeseries 集合或启用了 change stream 的集合上运行；执行前务必确认 config server 健康、各 shard 磁盘余量 >30%。
哈希 vs 范围分片在复合键里的实际影响
复合分片键里混用哈希和范围字段（如 {org_id: 1, log_id: "hashed"}）很常见，但要注意：MongoDB 只允许一个字段设为 "hashed"，其余必须是 1 或 -1。更重要的是，哈希字段**不能用于范围查询**——{org_id: "o-1", log_id: {$gt: "l-100"}} 这种写法会退化为广播，因为哈希值无序。
如果你的业务既要按组织隔离，又要按 ID 范围分页，更好的做法是：把时间维度（如 year_month）作为范围字段放左边，ID 哈希放右边，再配合 TTL 策略自动归档旧 chunk。这样 {year_month: "202610"} 能路由到固定分片组，而 {year_month: "202610", log_id: "l-123"} 可精准定位单个文档。
真正容易被忽略的一点是：复合分片键的字段顺序一旦固化，后续几乎无法调整。refine 和 reshard 都不支持「交换字段位置」。所以第一次定义时，就得把查询频率、基数、单调性三个维度一起压进脑子——它不是数据库配置，而是数据物理分布的宪法。
