mongodb 7.0未提供更高效哈希算法，仅支持固定md5哈希；提升序列写入性能关键在于预拆分足够chunk、禁用bulkwrite有序模式、增强分片键随机性，并确保chunk均匀分布。
MongoDB 7.0 分片集群本身不提供“更高效的哈希算法”来替代内置的 hashed 分片策略——它只支持一种哈希实现：MD5（对分片键值做 128 位哈希，再取低 64 位作为哈希值），且该逻辑在 7.0 中未变更。所谓“更高效”，实际是通过正确使用现有哈希机制 + 配合写入策略规避瓶颈，而非替换算法。
为什么不能自定义哈希函数
MongoDB 的 hashed 分片强制使用内部固定的哈希流程，客户端无法干预或替换底层哈希函数。驱动、mongosh 或 bulkWrite 均不暴露哈希计算接口；任何尝试在应用层预哈希（如用 SHA-256）再传入 {_id: "prehashed"} 的做法，会导致分片键失去分布性——所有预哈希值仍按字典序路由，退化为范围分片，丧失哈希的均匀性优势。
真正提升序列化写入吞吐的关键动作
海量序列化写入（如日志流水号、单调递增 ID）在哈希分片下仍可能热点，原因不在哈希算法慢，而在写入模式与 chunk 拆分节奏不匹配。需组合以下操作：
- 必须预拆分空集合：用
sh.splitAt()或sh.shardCollection(..., {numInitialChunks: 1024})主动创建足够多初始 chunk，避免所有写入挤在单个 chunk → 单个 shard 上 - 写入时显式禁用有序模式：对
db.collection.bulkWrite()设置{ordered: false}，让mongos并行发往多个 shard，否则默认ordered: true会串行阻塞 - 确保分片键含随机性：若原始 ID 单调（如
1,2,3...），直接哈希后低位仍可能聚集（MD5 对连续整数的低位碰撞概率不为零）。更稳妥的是改造分片键，例如：{shardKey: {ts: ISODate(), rand: Math.random()}}，再对rand字段哈希 - 避免在单个分片上堆积过多小 chunk：检查
sh.status()中各 shard 的 chunk 数量是否严重不均；若某 shard chunk 远少于其他，说明数据未打散，需重新评估分片键选择或预拆分数量
哈希分片 vs 范围分片在序列写入下的表现差异
对纯递增字段（如 order_id）：
- 范围分片（
{order_id: 1}）：所有新订单写入“最大 range”的 chunk，必然压在单个 shard，彻底丧失水平扩展能力 - 哈希分片（
{order_id: "hashed"}）：理论上均匀，但若集合为空且未预拆分，初始只有一个 chunk，所有写入仍落在一个 shard，直到 balancer 拆分并迁移——这个过程有延迟，期间写入能力被锁死在单节点
因此，“支持海量序列化写入”的核心不是哈希算法多快，而是**提前把数据槽位（chunk）铺开，并让写入流量真正并发出去**。
最容易被忽略的一点：预拆分数量必须与预期 shard 数量匹配。比如 3 个 shard，却只预拆 16 个 chunk，balancer 很难均匀分配；建议按 256 × shard_count 起手（如 3 shard → 768 chunk），并在写入压测中观察 sh.status() 的 chunk 分布和迁移延迟。
