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