Neo4j知識庫:初識Neo4j查詢?nèi)罩痉治銎?/h1>
原文鏈接: https://medium.com/neo4j/meet-the-query-log-analyzer-30b3eb4b1d6
原文鏈接: https://medium.com/neo4j/meet-the-query-log-analyzer-30b3eb4b1d6
查詢?nèi)罩痉治銎魇且粋€Neo4j桌面應(yīng)用，用于幫助了解Neo4j企業(yè)版服務(wù)器查詢?nèi)罩疚募?/p>
當(dāng)Neo4j突然變慢坪圾、或者查詢效率過低牌柄、再或者查詢負(fù)載過高時，這時最好的辦法就是查看查詢?nèi)罩尽６樵內(nèi)罩就ㄟ^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
一般情況下撬腾，設(shè)置一個閾值，當(dāng)請求超過這個時間（示例是100ms,或者設(shè)置為0装黑，代表所有請求）時副瀑，就會被記錄下來。這也意味著恋谭，查詢?nèi)罩局杏涗浀恼埱蟛⒉皇欠?wù)器上的所有查詢糠睡。但是這個工具仍然可以為你提供一個快速定位可能造成查詢瓶頸的方向。
在后續(xù)的文章中我將會做詳細(xì)的介紹疚颊。
當(dāng)在開發(fā)項(xiàng)目時狈孔，最好要經(jīng)常在開發(fā)服務(wù)器和測試服務(wù)器上分別去分析你的查詢?nèi)罩荆员惆l(fā)現(xiàn)問題材义。
工欲善均抽，必先利其器。接下來其掂，先看一下如何安裝查詢?nèi)罩痉治銎鳌?br> 下面是在Neo4j Desktop 1.1.10+安裝查詢?nèi)罩痉治銎鳌?br>
打開“Graph Aplications"側(cè)邊欄油挥，把URL (https://neo.jfrog.io/neo/api/npm/npm/query-log-analyzer)粘貼到"Insert Graph Application"輸入框中，按下”Install“按鈕。
選擇一個工程深寥，點(diǎn)擊應(yīng)用列表中的"+ Add Application"攘乒。
在這里增加“Query Log Analyzer”到你的工程中。
下面我來重點(diǎn)解釋一下查詢?nèi)罩痉治銎鳌?/p>
查詢?nèi)罩痉治銎?/h2>
查詢?nèi)罩痉治銎餍枰粋€query.log文件惋鹅。你將文件上傳到工具中则酝，然后它就開始分析。分析文件完成后负饲，將顯示下信息：
在上面的示例中的日志文件中堤魁，有17341行數(shù)據(jù)(一行一請求），有249個查詢被發(fā)現(xiàn)返十。這些查詢會顯示在“Query Analysis"標(biāo)簽頁中妥泉，你可以看到每個查詢的統(tǒng)計數(shù)據(jù)。
查詢分析
在Query Analysis標(biāo)簽頁中洞坑，不同的查詢是按 查詢次數(shù)*平均時間 降序排列的盲链。這樣的排序可以將最耗時的查詢排在最前面。
在Query Analysis標(biāo)簽頁中迟杂，有以下字段和功能：
The Query(在AvgTime?—?Avg Mem值的下面）
這是實(shí)際的查詢語句-
Query Count
日志文件中查詢的次數(shù)刽沾，對于這個查詢，還有下面一些功能可以使用:- Filter
在Query Log標(biāo)簽內(nèi)中排拷，只顯示這個查詢的查詢紀(jì)錄侧漓。 - Highlight
在Query Log標(biāo)簽內(nèi)中，高亮顯示這個查詢监氢。當(dāng)要看同時發(fā)到服務(wù)器的查詢時布蔗，會更便于查看。 - Timline
實(shí)驗(yàn)性的浪腐！在Query Timeline標(biāo)簽中今次顯示查詢
- Filter
Avg Time, Min Tim, Max Time
這里的時間是查詢執(zhí)行的累積時間（查詢+執(zhí)行計劃+等待）纵揍。-
Avg CPU
實(shí)際請求執(zhí)行所占CPU時間。當(dāng)詳細(xì)時間日志被禁用時议街，這里顯示0.
設(shè)置項(xiàng)：dbms.logs.query.time_logging_enabled=true dbms.track_query_cpu_time=true -
Max Planning
這是執(zhí)行計劃階段所花費(fèi)的最大時間泽谨，當(dāng)鼠標(biāo)懸停在該值上時，將會顯示最小時間和平均時間特漩。一般一個查詢第一次被觸發(fā)時吧雹，查詢生成執(zhí)行計劃，然后這個執(zhí)行計劃被放到查詢緩存中涂身，當(dāng)查詢再次被執(zhí)行時吮炕，生成執(zhí)行計劃的時間幾乎為0。當(dāng)執(zhí)行計劃被從緩存中移除時访得，下一個請求才會再次編譯成執(zhí)行計劃龙亲。當(dāng)Time logging被禁用時陕凹，此值顯示0.設(shè)置項(xiàng)：dbms.logs.query.time_logging_enabled=true -
Avg Waiting
查詢被執(zhí)行前的平均等待時間。這個等待可能是由于數(shù)據(jù)庫負(fù)載過重造成鳄炉，也可能是由于數(shù)據(jù)庫鎖造成的杜耙。當(dāng)Time logging被禁用時，此值顯示為0拂盯。設(shè)置項(xiàng)：dbms.logs.query.time_logging_enabled=true -
Cache Hits %
代表這個請求的數(shù)據(jù)有百分之多少是從緩存中讀取的佑女。100%意味著所有數(shù)據(jù)都是從緩存中讀取的。設(shè)置項(xiàng)：dbms.logs.query.page_logging_enabled=true -
Avg Mem
代表這個請求分配了多少內(nèi)存谈竿。注意团驱，這是一個累積值，表明了查詢的內(nèi)存占用情況空凸。設(shè)置項(xiàng)：dbms.logs.query.allocation_logging_enabled=true dbms.track_query_allocation=true -
Protocol + Clients
在請求的上下文中你可以看到所使用的協(xié)議嚎花。其值有：- bolt
一個blot客戶端連到數(shù)據(jù)庫。 - http
http客戶端使用Neo4j的rest接口呀洲。（Neo4j老版本使用） - embedded
來自數(shù)據(jù)庫內(nèi)部的調(diào)用紊选，像存儲過程或函數(shù)。
此外道逗，還有一個客戶端列表顯示兵罢，它列出了當(dāng)前有多少個不同IP向Neo4j服務(wù)器發(fā)出請求。注意滓窍，blot驅(qū)動是使用連接池連接數(shù)據(jù)庫的卖词，所以，你能看到1個IP會有多個客戶端吏夯。
- bolt
查詢?nèi)罩?/h2>
Query Log標(biāo)簽頁坏平，使用查詢?nèi)罩拘凶鳛榱藰?biāo)頭。更多的信息則需要拖動水平滾動條才能看到锦亦。在第一個Query Analysis標(biāo)簽頁里選擇一個查詢點(diǎn)擊“Highlight"，再點(diǎn)擊Filter時令境，就會跳到這個頁面杠园，且只顯示你選中的請求日志記錄。這時舔庶，你可以拷貝這個標(biāo)簽頁中的請求和參數(shù)去分析一個請求抛蚁。
Query Timeline
Query Timeline是一個實(shí)驗(yàn)性的功能，它繪制出了每時間段（默認(rèn)5分鐘）查詢總量和每秒種平均查詢次數(shù)惕橙。它是基于日志文件中記錄的時間瞧甩，而不是查詢開始時間。通過這張圖弥鹦，可以快速的了解到服務(wù)器是什么什么時候請求最多肚逸。
相關(guān)鏈接
查詢?nèi)罩痉治銎鞯脑创a在github的 kvegter/query-analyzer-app(https://github.com/kvegter/query-analyzer-app) 上爷辙，可以在那里閱讀文檔和報bug.
如果你有任何關(guān)于查詢性能的問題，可以前往Neo4j Users Slack或Neo4j Community上#help-cypher頻道咨詢朦促。
