了解 MongoDB 日誌中的 IXSCAN 和 COLLSCAN
我試圖通過一些 Mongo 日誌來查找我需要優化的慢速操作。預設情況下，慢查詢日誌記錄是記錄超過 100 毫秒的操作。
我認為可以肯定地說，一般來說，搜尋 COLLSCANS 會顯示需要注意的查詢。不太清楚的是，如果 IXSCANS 是我應該搜尋的細節。
考慮這裡的 MongoDB 文件：
https://docs.mongodb.com/manual/reference/explain-results/#collection-scan-vs-index-use
我的理解是這是一種二元情況，查詢是 COLLSCAN 或 IXSCAN。因此，如果我對 IXSCAN 進行 grep，我將查看所有不是 COLLSCANS 的慢查詢。這是真的？
我試圖通過一些 Mongo 日誌來查找我需要優化的慢速操作。預設情況下，慢查詢日誌記錄是記錄超過 100 毫秒的操作。
我強烈建議不要使用 MongoDB 日誌，而是使用開源
mtools項目中的腳本。注意：我不是mtools原作者，但我是貢獻者。
mtools是一個 Python 腳本的集合，其靈感來自於通過 GB 的日誌嘗試查找對生產 MongoDB 部署感興趣的資訊的痛苦。關鍵腳本旨在適應通過連續過濾器（例如mlogfilter --scan | mplotqueries）管道輸出的典型命令行工作流程。例如：
mloginfo --queries是一個很好的起點：它聚合了查詢模式，因此您可以專注於頻繁執行並對您的部署產生更大整體影響的查詢。mlogfilter本質上是 MongoDB 日誌的 grep：您可以按命名空間、持續時間、連接、模式和其他條件過濾日誌行。該--scan選項有助於辨識不一定是集合掃描的低效查詢。mplotqueries是一個視覺化日誌的工具，對於辨識模式和異常值非常有幫助。我認為可以肯定地說，一般來說，搜尋 COLLSCANS 會顯示需要注意的查詢。不太清楚的是，如果 IXSCANS 是我應該搜尋的細節。
集合掃描通常很有趣，但也可能是一次性查詢的結果或對小型集合的預期使用。我不會專注於查詢類型，而是會為您的部署審查慢查詢（或一般的慢操作），以便更好地了解您可以改進的地方。使用索引通常是好的，但是有一些低效的索引使用（例如記憶體排序或不區分大小寫的正則表達式）值得解決。
我的理解是這是一種二元情況，查詢是 COLLSCAN 或 IXSCAN。因此，如果我對 IXSCAN 進行 grep，我將查看所有不是 COLLSCANS 的慢查詢。這是真的？
如果您使用 grep 搜尋，
IXSCAN您將找到所有提及 的日誌行IXSCAN，但慢查詢日誌記錄結果絕對不是二進制的，並且還會因 MongoDB 伺服器版本而異。雖然有效的索引使用是一項明顯的優化，但有許多內部查詢規劃器階段可能與了解查詢性能有關。當您在日誌中發現有趣的慢查詢時，下一步通常是查看更詳細
explain output的 . 我使用explain(true)（又名allPlansExecution模式），因為這顯示了被考慮的查詢計劃的詳細資訊以及獲勝計劃。如果您不確定如何解釋慢查詢的解釋輸出，我建議您在DBA StackExchange上發帖。值得注意的是，解釋查詢並不是衡量工作負載實際性能的標準。在正常操作中，查詢計劃被記憶體，而詳細
explain的輸出專門重新評估候選索引和查詢計劃。有關更多資訊，請參閱MongoDB 手冊中的查詢計劃。