分片键基数太低会导致chunk均衡失败，因取值范围窄无法切分足够chunk，写入集中于单shard；后缀扩展可提升基数但需应用层控制后缀生成、保证一致性；哈希分片是更稳妥替代方案。
分片键基数太低会导致 chunk 均衡失败
当 _id 或业务字段（如 tenant_id）取值范围很窄，比如只有几十个固定值，MongoDB 无法切出足够多的 chunk，所有写入会持续打到同一个 shard 上。你看到 sh.status() 中某些 shard 的 chunk 数远高于其他节点，moveChunk 日志频繁报 cannot move chunk: no valid recipient found，本质就是没地方可搬——因为分片键值太少，chunk 边界无法有效分裂。
强行调小 chunkSize 没用：MongoDB 不允许对低基数分片键强制分裂，它会直接拒绝 split 操作，返回 cannot split chunk with low cardinality key range。
用后缀扩展分片键是可行但有代价的方案
核心思路是把单值字段（如 tenant_id: "abc"）改造成复合键，例如 {tenant_id: "abc", suffix: 1}，靠 suffix 提升整体基数。这要求你在写入时主动控制后缀生成逻辑，不能全靠随机或时间戳——否则会破坏范围查询效率。
- 后缀必须可预测、可枚举，比如按 0–99 循环，或按业务子域哈希取模（
Math.abs(hash(subdomain)) % 100） - 后缀字段类型要和主键一致（都用整数或都用字符串），避免隐式转换导致索引失效
- 必须在应用层保证同一业务实体的所有文档使用相同后缀，否则关联查询或聚合会跨 shard 扫描
- 如果原集合已有数据，需要停写 + 全量迁移，MongoDB 不支持在线修改分片键
更稳妥的替代方案：换用哈希分片键
如果业务允许牺牲范围查询能力（比如 tenant_id > "a" AND tenant_id 这类查询极少），直接把分片键设为 <code>{tenant_id: "hashed"} 是最省事的。MongoDB 内部用 64 位哈希，天然高基数，chunk 能均匀分布。
但要注意：
- 哈希后无法做
$gt/$lt范围扫描，只能走等值查询（{tenant_id: "abc"}） - 复合哈希不被支持，
{tenant_id: "hashed", created_at: 1}是非法语法 - 如果已有集合已用范围分片，必须重建集合（
mongodump→ 新集合启用哈希分片 →mongorestore）
后缀方案上线前必须验证的三件事
别只测插入，漏掉真实瓶颈点：
- 查一下
db.collection.getShardDistribution()，确认各 shard 的 doc count 和 storageSize 差距是否 ≤ 20% - 跑一次典型聚合（比如按
tenant_id分组统计），用explain("executionStats")看totalShardsVisited是否等于实际 shard 数——如果是，说明后缀没绑定好，触发了广播查询 - 压测时监控
shard01:27018的network/bytesIn和opcounters/insert，确认流量是否真的分散开；别只看 chunk 数，chunk 均衡不代表 I/O 均衡
后缀不是万能胶，它把分布问题转嫁给了应用层的一致性逻辑。一旦某个后缀值突然写入暴增（比如某子域流量突涨），那个 shard 依然会成为热点——这时候得配合读写分离或应用层限流，而不是再加一层后缀。
