在MongoDB中緩慢創建四字段索引

我在MongoDB中有一個ProductRequest集合。這是有點大集合，但沒有那麼多文件。文檔數量有點超過300,000，但文檔的平均大小接近1MB，因此數據佔用空間很大。在MongoDB中緩慢創建四字段索引

要加快某些查詢我設立指數這個集合：

db.ProductRequest.ensureIndex ({processed: 1, parsed: 1, error:1,processDate:1})

前三個字段是布爾值，最後一個是日期時間。

爲很快24小時內的命令運行，並且不會回來

我已經有指數「處理」和「解析」字段（一起）和「錯誤」的單獨一個。爲什麼創造這個四場指數會永遠持續下去？我的理解是，在這種情況下單個記錄的大小應該不重要，我錯了嗎？

附加信息：

MongoDB的版本2.6.1的64位

主機操作系統的Centos 6.5

拆分：是的，碎片關鍵是_id。分片數量：2，每個分片的副本集合數量爲3.

2014-10-20 henry

你確定你的終端連接不是簡單的消失嗎？你是否試圖檢查第二個mongo客戶端中是否存在索引？ – 2014-10-20 19:54:32

I belive其因布爾字段爲索引。由於只有兩個值（true或false），如果有300.000行將索引放在該字段中，則必須掃描150.00行以查找所有文檔，而在您的情況下，您有3個布爾字段，這會使其更慢。

2014-10-20 18:56:46 Disposer

與上述processDate上的索引相比，您不會從這三個字段的索引和processDate中看到巨大的收益。布爾型字段上的索引對於其他可索引字段的存在並不是很有用，因爲它們不是非常有選擇性。如果您提供處理日期，則其他字段的組合只有8種可能性，以通過索引進一步縮小結果範圍。

另外，您應該切換訂單。首先將processDate，因爲它比布爾字段更有選擇性。這應該大大簡化索引並加速索引構建。

最後，MongoDB中的索引創建有時不可避免地緩慢且昂貴，因爲它涉及到創建大型B樹。這個絕對值得的收益，當然是更快的查詢。索引編譯可能需要24小時以上。你有沒有檢查飽和資源是什麼？這可能是索引構建的CPU。此案例的最佳選擇是創建索引in the background。背景索引構建

你設定在後臺與一個額外的選項給ensureIndex調用發生索引構建：

db.myCollection.ensureIndex({ "myField" : 1 }, { "background" : 1 })

2014-10-21 05:16:20 wdberkeley

回答