共计 2813 个字符，预计需要花费 8 分钟才能阅读完成。
原文链接: 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
Query Timeline 是一个实验性的功能，它绘制出了每时间段（默认 5 分钟）查询总量和每秒种平均查询次数。它是基于日志文件中记录的时间，而不是查询开始时间。通过这张图，可以快速的了解到服务器是什么什么时候请求最多。
相关链接
查询日志分析器的源码在 github 的 kvegter/query-analyzer-app(https://github.com/kvegter/query-analyzer-app) 上，可以在那里阅读文档和报 bug. 如果你有任何关于查询性能的问题，可以前往 Neo4j Users Slack 或 Neo4j Community 上 #help-cypher 频道咨询。
