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

在Query Analysis標(biāo)簽頁中，有以下字段和功能：

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

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

Filter
在Query Log標(biāo)簽內(nèi)中，只顯示這個查詢的查詢紀錄。

Highlight
在Query Log標(biāo)簽內(nèi)中，高亮顯示這個查詢。當(dāng)要看同時發(fā)到服務(wù)器的查詢時，會更便于查看。

Timline
實驗性的！在Query Timeline標(biāo)簽中今次顯示查詢

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

Avg CPU
實際請求執(zhí)行所占CPU時間。當(dāng)詳細時間日志被禁用時，這里顯示0.
設(shè)置項：

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

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

dbms.logs.query.time_logging_enabled=true

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

dbms.logs.query.time_logging_enabled=true

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

dbms.logs.query.page_logging_enabled=true

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

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會有多個客戶端。