這其實是一個非常經典的難題多個欄位，任意組合搜尋，mongodb 我沒用過，但是我所知道的資料庫索引，遇到這類問題都是很頭大的。以mysql為例，不管你設定了幾個索引，單鍵的還是複合的，執行查詢的時候，最多隻能用到一個索引，記住這點，我姑且認為，mongodb也不例外。那麼，你任意組合欄位搜尋，是不是複合索引能滿足呢？不是比如你做了ABC三個欄位複合索引（注意順序）如果你查詢AB，這個索引是有效的，查詢A也沒問題，查詢AC，效率差一點，但是和查詢 A也差不太多，查詢BC，完蛋了，完全沒效率。這個索引毫無作用。那麼，設定索引的原則是什麼呢？查詢索引掃描行數最少！比如你查詢ABC，你設定了單鍵索引A，單鍵索引B，單鍵索引C，這裡哪個索引欄位的取值更分散，或者說哪個索引欄位的命中更少，用哪個索引效率就高，舉例說，你搜索了年齡和性別，用年齡做索引就比用性別做索引快。mysql裡，有時候資料庫不知道用什麼索引，需要force index一下（同一條SQL，不同版本會用到不同索引，效率差幾個數量級），mongodb我不清楚。我建議你從資料出發，基於真實場景的日誌，把業務體系裡常見的查詢濾出來，對最常見的查詢做針對性的索引最佳化，然後對非常不常見的查詢組合，從源頭是可以控制的。如果能正確理解索引掃描行數，對這個問題的認識就會清晰。然後把不同的查詢拿出來分析，會用到哪個索引，索引掃描行數會在什麼量級，這個可以認為和查詢效率基本上是線性相關的。
這其實是一個非常經典的難題多個欄位，任意組合搜尋，mongodb 我沒用過，但是我所知道的資料庫索引，遇到這類問題都是很頭大的。以mysql為例，不管你設定了幾個索引，單鍵的還是複合的，執行查詢的時候，最多隻能用到一個索引，記住這點，我姑且認為，mongodb也不例外。那麼，你任意組合欄位搜尋，是不是複合索引能滿足呢？不是比如你做了ABC三個欄位複合索引（注意順序）如果你查詢AB，這個索引是有效的，查詢A也沒問題，查詢AC，效率差一點，但是和查詢 A也差不太多，查詢BC，完蛋了，完全沒效率。這個索引毫無作用。那麼，設定索引的原則是什麼呢？查詢索引掃描行數最少！比如你查詢ABC，你設定了單鍵索引A，單鍵索引B，單鍵索引C，這裡哪個索引欄位的取值更分散，或者說哪個索引欄位的命中更少，用哪個索引效率就高，舉例說，你搜索了年齡和性別，用年齡做索引就比用性別做索引快。mysql裡，有時候資料庫不知道用什麼索引，需要force index一下（同一條SQL，不同版本會用到不同索引，效率差幾個數量級），mongodb我不清楚。我建議你從資料出發，基於真實場景的日誌，把業務體系裡常見的查詢濾出來，對最常見的查詢做針對性的索引最佳化，然後對非常不常見的查詢組合，從源頭是可以控制的。如果能正確理解索引掃描行數，對這個問題的認識就會清晰。然後把不同的查詢拿出來分析，會用到哪個索引，索引掃描行數會在什麼量級，這個可以認為和查詢效率基本上是線性相關的。