哈希分片适合写密集、分布不均场景，范围分片适合读多且需范围查询的离散键；选错导致热点或广播风暴，危及集群可用性；复合分片键{region:1,_id:"hashed"}可兼顾区域路由与数据打散。
哈希分片适合写密集、分布不均的场景；范围分片适合读多、需范围查询且分片键天然离散的业务。选错会导致热点或广播风暴，不是性能差一点，而是集群可用性直接受损。
哈希分片适用于单调增长字段但必须避免浮点数
当分片键是 _id（ObjectID）、时间戳、自增 ID 等单调递增值时，用哈希分片能强制打散写入压力。MongoDB 会自动调用哈希函数，你不需要手动算 convertShardKeyToHashed()，但要注意：
- 浮点数字段不能直接哈希：
hashed索引会把2.3、2.9都截断成2，导致哈希冲突，文档误路由 - 哈希后无法做范围查询：比如
{ ts: { $gt: ISODate("2026-01-01") } }会变成广播查询，所有分片都要扫描 - 等值查询（
{ _id: ObjectId("...") }）仍能精准路由到单一分片，这点不受影响
范围分片只在分片键高基数+低频+非单调时才安全
范围分片默认启用，但极易踩坑。它要求分片键本身具备天然的离散性，比如用户地区码（region_code）全国有 300+ 值且新增频率低。一旦选错，立刻出现热点：
- 用
city字段（仅 50 个取值）做范围分片 → 北上广深四地数据占 60%，对应分片 CPU 打满，其他分片空转 - 用
created_at时间戳做范围分片 → 新写入全部落到最新 chunk，该 chunk 所在分片 I/O 拉满，均衡器无法拆分（Jumbo Chunk） - 即使基数够高，若字段值集中在某几个区间（如 90% 用户注册在近 30 天），仍会形成隐性热点
复合分片键里混用哈希与范围前缀是折中解法
真实业务很少有“完美”的单字段分片键，常用 { region: 1, _id: "hashed" } 这类组合。前缀字段（region）支持区域分片（Zone），后缀哈希字段（_id）保障本区域内数据均匀。这种设计下：
- 按
region查询可命中单一分片或指定 Zone，不广播 - 按
_id查询仍能精准定位，但跨region的等值查询会广播到所有该 region 对应的分片 - 必须先为
region建普通索引，再建复合索引，否则sh.shardCollection()会失败 - 注意：MongoDB 不允许对已分片集合的分片键加字段以外的修改，5.0+ 的
reshardCollection会额外占用 2 倍磁盘空间
真正难的不是语法怎么写，而是判断业务流量模式是否匹配分片策略——写入是不是集中在某个时间窗口？查询是不是总带某个业务维度？这些比 sh.shardCollection() 多敲一个参数要命得多。
