MongoDB分片集群的核心任务是把一个逻辑集合的数据分散到多个物理分片上，从而突破单机存储和计算瓶颈。分片策略决定了数据如何路由，其中最常被拿来对比的就是范围分片和哈希分片。范围分片按照分片键的值从小到大划分chunk，查询连续区间的效率很高，但如果分片键是自增的ObjectId或时间戳，新写入的数据会全部落到最后一个chunk，造成单个分片压力过大。哈希分片则在写入前先对分片键做一次哈希计算，把原本连续的数据打散，再根据哈希值所属的chunk范围决定写入哪个分片。这种方式牺牲了一部分范围扫描性能，换来了更均匀的数据分布。接下来详细拆解哈希分片的内部过程。

哈希分片的核心原理

MongoDB哈希分片并不保存原始分片键作为chunk边界，而是使用分片键的哈希值来划分chunk。当插入文档时，mongos会使用相同的哈希函数计算分片键的哈希值，得到一个64位整数。该哈希值落在某个chunk的[minKey, maxKey)区间内，于是文档被路由到该chunk对应的shard。默认情况下，chunk大小是64MB，当某个chunk数据量超过限制，MongoDB会触发chunk分裂，将哈希值范围一分为二。如果分片之间chunk数量差异达到迁移阈值，balancer会迁移整个chunk，而不是迁移单条文档。这个机制意味着哈希分片的数据均匀程度取决于哈希函数质量、分片键基数以及chunk边界划分。

MongoDB使用一种基于MD5的哈希算法，对分片键的值生成64位整数。具体来说，MongoDB内部将分片键值进行规范化，例如数值类型保持原样，字符串按UTF-8字节处理，然后计算MD5摘要并取前8个字节转换为长整型。这种做法能保证相同原始值一定映射到相同的哈希值，且哈希空间足够大，不容易出现碰撞。需要注意，MongoDB哈希分片只支持单个字段作为分片键，不能直接用复合字段做哈希索引。例如可以设置_id作为哈希分片键，也可以设置userId、orderNo等字段，但如果业务经常按userId + createTime联合查询，哈希分片也只能选择其中一个字段，否则无法利用分片键路由。

// 在分片集群中启用数据库分片
sh.enableSharding("orderdb")
// 对 orderdb.orders 集合使用 orderId 字段做哈希分片
sh.shardCollection("orderdb.orders", { orderId: "hashed" })
// 如果集合已存在，可以先创建哈希索引再手动分片
db.orders.createIndex({ orderId: "hashed" })
sh.shardCollection("orderdb.orders", { orderId: "hashed" })

哈希分片与范围分片的对比

从数据分布角度看，范围分片把相邻的分片键值放进同一个chunk，因此查询一个连续范围时只需要访问少数几个shard，非常适合时序数据、按日期范围扫描以及分片键有自然顺序的业务。但如果写入模式是单调递增，比如使用ObjectId的_id或自增主键，范围分片会持续把数据写入最后一个chunk，导致热点问题。哈希分片则把相邻的原始值映射到完全不同的哈希区间，从而让写入均匀分散到所有shard。一个常见的场景是订单系统使用orderId作为分片键，订单号虽然是递增的，但哈希后写入分布基本均衡。

查询模式上，哈希分片的优点是单条记录的等值查询非常高效。例如查询db.orders.find({ orderId: "202412010001" })时，mongos可以立即计算出哈希值，只路由到对应分片。但范围查询会变慢，因为$gt、$lt这类条件无法通过哈希值定位连续区间，mongos必须把查询广播到所有分片，再合并结果。聚合查询和排序也会受到类似影响。如果业务频繁执行按用户Id查单条记录，哈希分片很适合；如果频繁按时间范围扫描日志，范围分片更合适。混合方案可以考虑在范围分片基础上，使用分片键为时间戳和时间戳的哈希组合，但MongoDB原生哈希分片只支持单字段，需要在应用层做映射或选择其他字段。

下面用一张表对比两者在关键维度上的差异：

哈希分片键选择与配置实践

选择哈希分片键时，首先要看字段基数。如果基数太低，例如性别、状态、省份等，即使哈希后分布很均匀，但最多只有几个不同的哈希值，chunk数量也会受限于基数，无法充分利用所有分片。理想的哈希分片键应该具备高基数、值分布相对随机，并且绝大多数查询都包含这个字段。比如用户中心可以用userId、交易系统可以用transactionId、日志系统如果用哈希分片则可以用traceId。单调递增的订单号虽然原始值连续，但经过哈希后会打散，因此也适合作为哈希分片键。

配置哈希分片时，需要先确认mongos和config server可用，并且目标数据库已经启用分片。如果集合已经存在，MongoDB要求分片键上有对应的索引。对于哈希分片，可以提前创建hashed索引，也可以让sh.shardCollection自动创建。命令中的{ orderId: "hashed" }就是在告诉MongoDB使用哈希分片策略，而不是范围分片。创建完成后，MongoDB会为这个集合创建若干个初始chunk，默认按哈希值空间平均划分。后续随着数据写入，chunk分裂和迁移会自动进行。我们可以通过sh.status()查看集合的分片状态、chunk分布以及balancer是否开启。

// 1. 连接到mongos并添加分片
mongos> sh.addShard("rs1/host1:27018,host2:27018,host3:27018")
mongos> sh.addShard("rs2/host4:27018,host5:27018,host6:27018")
// 2. 启用数据库分片
mongos> sh.enableSharding("appdb")
// 3. 使用哈希分片键创建分片集合
mongos> sh.shardCollection("appdb.orders", { orderNo: "hashed" })
// 4. 查看分片状态
mongos> sh.status()

哈希分片常见误区与性能调优

一个典型误区是认为只要使用哈希分片，数据分布就绝对均匀。实际上如果分片键基数不够高，或者数据原始分布极端倾斜，哈希后仍然可能出现chunk大小不均衡。例如将country字段作为哈希分片键，虽然哈希函数能把不同国家映射到不同哈希区间，但国家数量有限，初始chunk可能只有几十个，当分片数量增加后无法充分利用。另一个误区是低估了范围查询的代价。有些团队在订单系统上使用哈希分片后，后台管理页面经常按时间区间导出数据，结果每次导出都广播到所有分片，导致集群压力骤增。应当在应用层增加查询条件约束，或者将数据双写到按时间范围分片的只读副本中。

性能调优方面，首先要关注balancer的迁移频率。哈希分片在数据增长阶段，chunk会频繁分裂和迁移，如果迁移速度跟不上写入速度，可能造成单分片瞬时热点。可以适当调整chunk大小，例如将默认64MB提高到128MB或256MB，减少chunk分裂次数，但过大的chunk会增加迁移成本，需要根据数据量和网络条件折中。其次要留意分片键的索引选择。哈希索引只能用于等值查询，不能加速范围查询和排序。如果业务有排序需求，可以考虑在应用层查询出数据后排序，或者使用其他字段的二级索引，但要注意二级索引在分片集群中也有额外开销。

监控维度上，建议持续关注每个shard的写入延迟、chunk数量以及balancer锁等待时间。当发现某个shard的oplog增长明显快于其他shard时，可能存在热点，此时要检查分片键基数、查询模式是否发生了变化。通过sh.status()和db.collection.getShardDistribution()可以查看数据分布情况。例如getShardDistribution会输出每个shard的文档数量和磁盘占用占比，帮助判断是否需要调整分片键。需要注意的是，修改分片键和分片策略需要重建集合或结合在线迁移工具，成本较高，因此初始化设计时必须充分评估未来的查询和写入模式。