假設我有以下架構：- 集合名稱-Test
{
"uid": "5e0e6a804888946fa61a1976",
"name": "abc",
"bookName":"xyz",
"rating": 5,
"category":"aa",
"isbn":"45656"
}
我的主要查詢是通過"uid". 用例是，用戶可以根據否進行過濾。欄位和任何組合。為eg 1:. 他選擇name :'abc'，然后選擇'rating' as '5'，下一個eg 2:；他可以選擇cat: "some cat"和name :"some name"。
在模式上有索引/復合索引的有效方法是什么？這將適用于任何組合和任何否。用戶選擇的欄位。如何使用索引覆寫查詢？
currently for eg1:我可以創建索引-{name:1, rating:1}
for eg2:我可以創建索引{cat:1, name:1}
- 但是在沒有定義用戶如何選擇過濾器的順序的情況下？我該如何解決？我是否需要使用每種可能的組合創建所有索引？
請幫助，并提出任何想法。
我的查詢是動態的，find基于用戶對過濾器的選擇，但 uid 是恒定的。
uj5u.com熱心網友回復：
處理“任意組合中的任意數量的欄位”型別的場景沒有靈丹妙藥。您必須確定哪些查詢對您的應用程式最關鍵，并創建支持它們的索引。不那么頻繁的查詢可能最好只部分支持。
設計索引的最佳整體策略是使用與您將在生產中運行的資料集相似的資料集來分析各種索引配置，以查看哪些配置執行得最好。檢查為您的集合創建的當前索引，以確保它們支持您當前和計劃的查詢。如果不再使用某個索引，請洗掉該索引。[1]
為什么不為每個可能的欄位組合創建所有索引？因為
索引會帶來性能成本，但對于大型資料集的頻繁查詢來說，它的成本是值得的。考慮應用程式中每個查詢的相對頻率以及查詢是否證明索引是合理的。[1]（強調我的）。
因此，您需要提前仔細計劃查詢，或者設定一個暫存環境并在查詢模式出現時觀察它們，并修剪不能證明它們存在的索引。
最后，我個人的建議是確保您了解 ESR 規則[2]，并創建幾個復合索引牢記此規則，然后密切關注 MongoDB 部署的執行情況。資料訪問模式最終可能不像最初看起來那樣隨意。
我絕不是在告訴你 ESR 規則是你唯一需要知道的，以便提出有效的索引策略。還有更多。[3]
[1] https://www.mongodb.com/docs/manual/applications/indexes
[2] https://www.mongodb.com/docs/manual/tutorial/equality-sort-range-rule
[3] https://www.mongodb.com/blog/post/performance-best-practices-indexing
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/481734.html