建立的索引要匹配查詢。

db.posts.find({ slug : 'state-of-mongodb-2010' })

db.posts.ensureIndex({ slug: 1 }, {unique: true});

db.comments.find({ tags : 'mongodb'}).sort({ created_at : -1 });

db.comments.ensureIndex({tags : 1, created_at : -1});

每個查詢一個索引。

要確定所有的索引都在RAM中。

db.comments.totalIndexSize();

65443

要小心單鍵索引的低選擇性。

使用explain.

db.comments.find({ tags : 'mongodb'}).sort({ created_at : -1 }).explain();

理解explain的輸出.

要關注應用讀/寫( read/write) 比率

這個很重要，因為，新增索引意味著新增，更新，刪除操作變慢。

如果你的應用是偏向於讀取，使用索引是非常好的事情。

但是如果你的應用偏向於寫，那麼建立索引就要小心了。增加索引都很影響寫入的效能。

一般來說, 不要隨便新增索引。索引應該按照你的查詢來新增。

新增索引的理由總是很多的, 以及要進行大量的測試選擇合適的索引策略。

索引特性

組合索引有許多特性要記住。

下面的例子都假想在 a, b, c上建立組合索引。因此建立索引語句如下

db.foo.ensureIndex({a: 1, b: 1, c: 1})

1. 排序的列一定要在索引的最後。

好的:

不好的:

2，3 ，4在1.6+已經不適用了。推薦使用1.6+以上版本。
 

5. MongoDB's $ne 或者$nin 操作在索因傷是無效的。

=============

MongoDB範圍查詢的索引優化

我們知道，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} 的聯合索引會比較合適。當然，這裡只是提供了多一種思路，具體是否採用還是需要視你的資料情況而定。

來源：architects.dzone.com

我在百X知道上回答問題時經常遇到類似與這樣的問題：MongoDB有沒有像MySQL一樣的ODBC驅動？MongoDB能不能像MySQL一樣獲取欄位名稱或型別。

我的回答是：不行，因為MongoDB不是MySQL。這個回答顯得MongoDB太弱了，我的原意是你不能要求一個物理優秀教師幫你輔導數學，也許他能做到基本的教學，但他很難做到優秀數學教師那麼全面。

今天討論的問題是：批量插入和批量查詢

昨天在百X知道上有人問起MongoDB的批量插入如何寫，這個我還真沒用過，一方面MongoDB的速度足夠快讓我從來沒有想過去找這種方法，另一方面MongoDB的官網以及API裡也找不到這種方法。

那就帶來兩個問題。

問題1：這樣豈不是沒有速度更快的批量插入麼？

這個問題毫無技術含量，MongoDB怎麼可能會比MySQL慢？這裡還是涉及到大家經常用到的傳統關係型資料庫和NoSQL的本質區別問題，NoSQL的每次操作都非常輕量級，小型化，除了資料的寫入外基本沒有多餘的操作。再舉個栗子：MongoDB就是放東西（資料）時把東西扔入相應的櫃子（資料庫）即可，而MySQL則要保持與送東西人的溝通（雙向連線保持），東西的摺疊整理分格儲存（事務+有模式）。MySQL的批量插入就是減少了溝通以及分格等過程，而MongoDB本身就不存在這些過程，因此MongoDB就不存在批量插入這個概念了。結論就是，MongoDB的普通插入比MySQL的批量插入還要快，或者說MongoDB的普通插入就是批量插入。

問題2：把多個操作放入一個事務裡一起執行不就不能實現了？

這個問題更沒有技術含量了，MongoDB有事務麼？還是那句，不要把NoSQL當關系型資料庫用。那豈不是MongoDB的資料完整性和資料安全性會很差？這個，還得再重複一遍，MongoDB的設計是為了處理大規模資料的，所以對資料完整性要求不是那麼嚴格。如果非要較真兒的話，MongoDB也可以處理這種情況，就是getLastError，它會犧牲效能以獲取資料操作是否正確，你可以在批量插入一批資料後呼叫一次這個方法，如果出錯，就把這批資料重新操作一遍，一批呼叫getLastError一次，既可保證效能，又可保證資料安全。

批量查詢

再來說一下批量查詢，這裡的批量對應於官網上的batch select的概念，可以理解為一次查詢一批資料。很多人在使用資料庫的時候會用：

Statement stmt = a.createStatement();

ResultSet rs = stmt.executeQuery(sql);

for(int i = 1; i < 10000; i++){

//read data from rs

}

這樣操作，會把資料庫中的資料全部讀入記憶體還是每條資料都去資料庫中讀一次？實際上兩者都不是，MySQL會把部分資料放入記憶體，如果這部分資料讀完了，那麼再讀入一部分。因為很久沒用MySQL了，我記得C++的驅動中確實有一個類是用於把全部資料都讀入記憶體的，不過這種方法很少人使用。

MongoDB的查詢是這樣的，你用Cursur去查詢，如果沒有設定batch size這個引數，那麼MongoDB預設會返回101條資料，等到這101條資料讀完了，也就是說使用者想讀第102條資料，那麼驅動會再次去MongoDB中獲取後面的一批資料，這批資料不是以個數記的，而是最大限制4M的大小，將這4M的資料返回供使用者繼續讀，讀完再申請4M。當然，你可以通過batch size來改變這一數值，如果設定了，那麼每次返回都會返回batch size條資料。

通過db.system.profile.find() 檢視當前的監控日誌.