Create a sharded DB environment - 3 shards (just one mongod per shard), 1 config server and 1 mongos. Important to have more than 2 shards to easily distinguish the erroneous 2 shard routing behaviour from a general scatter-gather to all 3 shards behaviour. Using mongo shell, via mongos ensure you have called addShard() for each of the 3 shards Load up a database (eg. 'test') with a collection of randomly generated documents - 2 million small docs should be sufficient to allow some chunking to occur. sh.enableSharding( 'test' ) use test db.rawdata.ensureIndex({myfield: 1}) sh.shardCollection( 'test.rawdata' , {myfield: 1}) for ( var i = 0; i < 2000000; ++i) { db.rawdata.insert({myfield: Math .floor( Math .random()*10000)}); } See what chunks are on what shards sh.status() Run a query on a subset of data that lives on just once shard (eg. choose one chunk start and end value from the chunk list above and just query that), IMPORTANT - choose a value where the next chunk after it lives on different shard <-- THIS IS KEY // Change the 2 values as appropriate db.rawdata.find({ "myfield" : { "$gte" : 80, "$lt" : 1059}}).explain() Notice in the explain output, 2 shards are being targeted when should only need to target one, because the shard key range used in the find() belongs to just one shard Modify the find to use $lte and decrement the value by 1 // Change the 2 values as appropriate db.rawdata.find({ "myfield" : { "$gte" : 80, "$lte" : 1058}}).explain() This time notice that now only one shard is correctly being targeted in the explain plan The aggregation framework exhibits the same behaviour. // Change the 2 values as appropriate var pipeline = [{ "$match" : { "myfield" : { "$gte" : 80, "$lt" : 1059}}}] db.rawdata.aggregate(pipeline, {explain: true });