为何MongoDB哈希分片键在无数据时预先生成分片块？

Great question! This behavior boils down to the core design priorities and fundamental differences between hashed sharding and range-based sharding (including compound shard keys) in MongoDB. Let’s break it down clearly:

1. Hashed Sharding is Optimized for Immediate Uniform Distribution #

Hashed shard keys work by computing a hash value for your target field (like sampleId in your example) that falls within a fixed, predictable range. MongoDB knows exactly the full scope of possible hash values—from $minKey to $maxKey, mapped to a consistent numeric range.

To ensure data is evenly spread across shards the second you start inserting documents, MongoDB pre-splits this fixed hash space into equal-sized chunks by default. In your 2-shard setup, this means splitting the entire hash range into 4 total chunks (2 per shard) right away—no data required. This way, when you add documents, their hashed sampleId values will map directly to these pre-existing chunks, avoiding the initial bottleneck of all data landing on one shard.

Here’s your hashed shard key example for reference:

sample.test shard key: { "sampleId" : "hashed" }
unique: false
balancing: true
chunks:
shard001 2
shard002 2
{ "sampleId" : { "$minKey" : 1 } } --> { "sampleId" : NumberLong("-4611686018427387902") } on : shard001 Timestamp(1, 0)
{ "sampleId" : NumberLong("-4611686018427387902") } --> { "sampleId" : NumberLong(0) } on : shard001 Timestamp(1, 1)
{ "sampleId" : NumberLong(0) } --> { "sampleId" : NumberLong("4611686018427387902") } on : shard002 Timestamp(1, 2)
{ "sampleId" : NumberLong("4611686018427387902") } --> { "sampleId" : { "$maxKey" : 1 } } on : shard002 Timestamp(1, 3)

2. Range/Compound Sharding Relies on Actual Data Growth #

Range-based sharding (including compound keys like { "sampleId" : 1, "uid" : 1 }) operates differently. The possible values for these keys are unbounded and unpredictable—sampleId could be any integer, uid could be any value, with no fixed upper or lower limit.

Since MongoDB can’t pre-divide an unknown, open-ended range into meaningful chunks, it starts with one single chunk that covers the entire possible range of the shard key. This chunk only splits into smaller pieces when it reaches the default size threshold (64MB) as you insert data. Only then will the balancer begin moving chunks to other shards if needed.

Your range/compound shard key example perfectly shows this:

sample.test shard key: { "sampleId" : 1, "uid" : 1 }
unique: false
balancing: true
chunks:
shard002 1
{ "sampleId" : { "$minKey" : 1 }, "uid" : { "$minKey" : 1 } } --> { "sampleId" : { "$maxKey" : 1 }, "uid" : { "$maxKey" : 1 } } on : shard002 Timestamp(1, 0)

Quick Recap #

• Hashed sharding: Pre-splits the fixed hash space upfront to enable instant even data distribution, ideal for fields with random or unordered values.
• Range/compound sharding: Starts with one chunk and splits only as data grows, optimized for use cases where you need to query by ranges of the shard key (e.g., time intervals, sequential IDs).

内容的提问来源于stack exchange，提问作者madman01234