摘要：原文鏈接查詢日志分析器是一個桌面應用，用于幫助了解企業版服務器查詢日志文件。下面是在安裝查詢日志分析器。當被禁用時，此值顯示設置項查詢被執行前的平均等待時間。設置項代表這個請求的數據有百分之多少是從緩存中讀取的。

原文鏈接: https://medium.com/neo4j/meet...

查詢日志分析器是一個Neo4j桌面應用，用于幫助了解Neo4j企業版服務器查詢日志文件。

當Neo4j突然變慢、或者查詢效率過低、再或者查詢負載過高時，這時最好的辦法就是查看查詢日志。而查詢日志通過neo4j.conf文件配置的。

dbms.logs.query.enabled=true
# If the execution of query takes more time than this threshold, 
# the query is logged. If set to zero then all queries
dbms.logs.query.threshold=100ms
dbms.logs.query.parameter_logging_enabled=true
dbms.logs.query.time_logging_enabled=true
dbms.logs.query.allocation_logging_enabled=true
dbms.logs.query.page_logging_enabled=true
dbms.track_query_cpu_time=true
dbms.track_query_allocation=true

一般情況下，設置一個閾值，當請求超過這個時間（示例是100ms,或者設置為0，代表所有請求）時，就會被記錄下來。這也意味著，查詢日志中記錄的請求并不是服務器上的所有查詢。但是這個工具仍然可以為你提供一個快速定位可能造成查詢瓶頸的方向。
在后續的文章中我將會做詳細的介紹。
當在開發項目時，最好要經常在開發服務器和測試服務器上分別去分析你的查詢日志，以便發現問題。

工欲善其事必先利其器。接下來，先看一下如何安裝查詢日志分析器。
下面是在Neo4j Desktop 1.1.10+安裝查詢日志分析器。

打開“Graph Aplications"側邊欄，把URL (https://neo.jfrog.io/neo/api/...到"Insert Graph Application"輸入框中，按下”Install“按鈕。

選擇一個工程，點擊應用列表中的"+ Add Application"。

在這里增加“Query Log Analyzer”到你的工程中。

下面我來重點解釋一下查詢日志分析器。

查詢日志分析器需要一個query.log文件。你將文件上傳到工具中，然后它就開始分析。分析文件完成后，將顯示下信息：

在上面的示例中的日志文件中，有17341行數據(一行一請求），有249個查詢被發現。這些查詢會顯示在“Query Analysis"標簽頁中，你可以看到每個查詢的統計數據。

在Query Analysis標簽頁中，不同的查詢是按 查詢次數*平均時間 降序排列的。這樣的排序可以將最耗時的查詢排在最前面。

在Query Analysis標簽頁中，有以下字段和功能：

The Query(在AvgTime?—?Avg Mem值的下面）
這是實際的查詢語句

Query Count
日志文件中查詢的次數，對于這個查詢，還有下面一些功能可以使用:

Filter
在Query Log標簽內中，只顯示這個查詢的查詢紀錄。

Highlight
在Query Log標簽內中，高亮顯示這個查詢。當要看同時發到服務器的查詢時，會更便于查看。

Timline
實驗性的！在Query Timeline標簽中今次顯示查詢

Avg Time, Min Tim, Max Time
這里的時間是查詢執行的累積時間（查詢+執行計劃+等待）。

Avg CPU
實際請求執行所占CPU時間。當詳細時間日志被禁用時，這里顯示0.
設置項：

dbms.logs.query.time_logging_enabled=true
dbms.track_query_cpu_time=true

Max Planning
這是執行計劃階段所花費的最大時間，當鼠標懸停在該值上時，將會顯示最小時間和平均時間。一般一個查詢第一次被觸發時，查詢生成執行計劃，然后這個執行計劃被放到查詢緩存中，當查詢再次被執行時，生成執行計劃的時間幾乎為0。當執行計劃被從緩存中移除時，下一個請求才會再次編譯成執行計劃。當Time logging被禁用時，此值顯示0.設置項：

dbms.logs.query.time_logging_enabled=true

Avg Waiting
查詢被執行前的平均等待時間。這個等待可能是由于數據庫負載過重造成，也可能是由于數據庫鎖造成的。當Time logging被禁用時，此值顯示為0。設置項：

dbms.logs.query.time_logging_enabled=true

Cache Hits %
代表這個請求的數據有百分之多少是從緩存中讀取的。100%意味著所有數據都是從緩存中讀取的。設置項：

dbms.logs.query.page_logging_enabled=true

Avg Mem
代表這個請求分配了多少內存。注意，這是一個累積值，表明了查詢的內存占用情況。設置項：

dbms.logs.query.allocation_logging_enabled=true
dbms.track_query_allocation=true

Protocol + Clients
在請求的上下文中你可以看到所使用的協議。其值有：

bolt
一個blot客戶端連到數據庫。

http
http客戶端使用Neo4j的rest接口。（Neo4j老版本使用）

embedded
來自數據庫內部的調用，像存儲過程或函數。

此外，還有一個客戶端列表顯示，它列出了當前有多少個不同IP向Neo4j服務器發出請求。注意，blot驅動是使用連接池連接數據庫的，所以，你能看到1個IP會有多個客戶端。

Query Log標簽頁，使用查詢日志行作為了標頭。更多的信息則需要拖動水平滾動條才能看到。在第一個Query Analysis標簽頁里選擇一個查詢點擊“Highlight"，再點擊Filter時，就會跳到這個頁面，且只顯示你選中的請求日志記錄。這時，你可以拷貝這個標簽頁中的請求和參數去分析一個請求。

Query Timeline是一個實驗性的功能，它繪制出了每時間段（默認5分鐘）查詢總量和每秒種平均查詢次數。它是基于日志文件中記錄的時間，而不是查詢開始時間。通過這張圖，可以快速的了解到服務器是什么什么時候請求最多。

查詢日志分析器的源碼在github的 kvegter/query-analyzer-app(https://github.com/kvegter/query-analyzer-app) 上，可以在那里閱讀文檔和報bug.
如果你有任何關于查詢性能的問題，可以前往Neo4j Users Slack或Neo4j Community上#help-cypher頻道咨詢。