我們知道，MongoDB的索引是B-Tree結構的，和MySQL的索引非常類似。所以你應該聽過這樣的建議：創建索引的時候要考慮到sort操作，盡量把sort操作要用到的字段放到你的索引后面。但是有的情況下，這樣做反而會使你的查詢性能更低。

問題

比如我們進行下面這樣的查詢：

db.collection.find({"country": "A"}).sort({"carsOwned": 1}) 

查詢條件是 {“country”: “A”}，按 carsOwned 字段的正序排序。所以索引就很好建了，直接建立 country , carsOwned 兩個字段的聯合索引即可。像這樣：

db.collection.ensureIndex({"country": 1, "carsOwned": 1}) 

我們來看一個稍微復雜一點的查詢：

db.collection.find({"country": {"$in": ["A", "G"]}}).sort({"carsOwned": 1}) 

這回我們是要查詢 country 為 A 或者 G 的數據條目，結果同樣按 carsOwned 字段排序。

如果我們還使用上面的索引，并且使用 explain() 分析一下這個查詢，就會發現在輸出中有一個“scanAndOrder” : true 的字段，并且 nscanned 的值可能會比想象中的大很多，甚至指定了 limit 也沒什么效果。

原因

這是什么原因呢，我們先看下面這張圖：

如上圖所未，左邊一個是按 {“country”: 1, “carsOwned”: 1} 的順序建立的索引。而右邊是按{“carsOwned”: 1, ”country”: 1} 順序建立的索引。

如果我們執行上面的查詢，通過左邊的索引，我們需要將 country 值為A的（左圖的左邊一支）所有子節點以及country 值為G的（左圖的右邊一支）所有子節點都取也來。然后再對取出來的這些數據按 carsOwned 值進行一次排序操作。

所以說上面 explain 輸出了一個 “scanAndOrder” : true 的提示，就是說這次查詢，是先進行了scan獲取到數據，再進行了獨立的排序操作的。

那如果我們使用右邊的索引來做查詢，結果就不太一樣了。我們沒有將排序字段放在***，而是放在了前面，相反把篩選字段放在了后面。那這樣的結果就是：我們會從值為1的節點開始遍歷（右圖的左邊一支），當發現有 country 值為 A 或 G 的，就直接放到結果集中。當完成指定數量（指定 limit 個數）的查找后。我們就可以直接將結果返回了，因為這時候，所有的結果本身就是按 carsOwned 正序排列的。

對于上面的數據集，如果我們需要2條結果。我們通過左圖的索引需要掃描到4條記錄，然后對4條記錄進行排序才能返回結果。而右邊只需要我們掃描2條結果就能直接返回了（因為查詢的過程就是按需要的順序去遍歷索引的）。

所以，在有范圍查詢（包括$in, $gt, $lt 等等）的時候，其實刻意在后面追加排序索引通常是沒有效果的。因為在進行范圍查詢的過程中，我們得到的結果集本身并不是按追加的這個字段來排的，還需要進行一次額外的排序才行。而在這種情況下，可能反序建立索引（排序字段在前、范圍查詢字段在后）反而會是一個比較優的選擇。當然，是否更優也和具體的數據集有關。

總結

總結一下，舉兩個栗子。

當查詢是：

db.test.find({a:1,b:2}).sort({c:1}) 

那么直接建立 {a:1, b:1, c:1} 或者 {b:1, a:1, c:1} 的聯合索引即可。

如果查詢是：

db.test.find({a:1,b:{$in:[1,2]}}).sort({c:1}) 

那么可能建立 {a:1, c:1, b:1} 的聯合索引會比較合適。當然，這里只是提供了多一種思路，具體是否采用還是需要視你的數據情況而定。

原文鏈接：http://blog.nosqlfan.com/html/4117.html

【編輯推薦】

1. 先睹為快：甲骨文NoSQL數據庫
2. 八種主流NoSQL數據庫系統對比
3. 解讀NoSQL數據庫的四大家族
4. NoSQL在企業中的發展歷程
5. 一個初創公司是否適用NoSQL引發的探討