neo4j查询的复杂性

我需要衡量任何查询的性能

例如：

MATCH (n:StateNode)-[r:has_city]->(n1:CityNode)
WHERE n.shortName IN {0} and n1.name IN {1} 
WITH n1
Match (aa:ActiveStatusNode{isActive:toBoolean('true')})--(n2:PannaResume)-[r1:has_location]->(n1)
WHERE (n2.firstName="master") OR (n2.lastName="grew" )
WITH n2  
MATCH (o:PannaResumeOrganizationNode)<-[h:has_organization]-(n2)-[r2:has_skill]->(n3:Skill)
WHERE (0={3} OR o.organizationId={3}) AND (0={4} OR n3.name IN {2} OR n3.name IN {5}) 
WITH size(collect(n3)) as count, n2 
MATCH (n2) where (0={4} OR count={4}) 
RETURN DISTINCT n2 

匹配（n:StateNode）-[r:has\u city]->（n1:CityNode）
其中{0}中的n.shortName和{1}中的n1.name
带n1
匹配（aa:ActiveStatusNode{isActive:toBoolean（'true'）}）-（n2:PannaResume）-[r1:has_location]->（n1）
其中（n2.firstName=“master”）或（n2.lastName=“growth”）
含氮
匹配（o:PannaResumeOrganizationNode）（n3:Skill）
其中（0={3}或o.organizationId={3}）和（0={4}或{2}中的n3.name或{5}中的n3.name）
以大小（收集（n3））作为计数，n2
匹配（n2），其中（0={4}或count={4}）
返回不同的n2

---

我尝试了profile&explain子句，但它们只返回db命中数。有没有可能为neo4j查询获得大的符号，即我们用大的O符号来衡量性能？除了使用profile&explain之外，还有其他检查查询性能的方法吗？

配置文件结果显示neo4j服务器实际计划如何处理您的Cypher查询。您需要分析概要文件结果显示的执行计划，以获得大的O复杂性。我知道没有工具可以做到这一点（尽管有人创建一个工具会是一个好主意）

---

您还应该注意，查询的执行计划可能会随着数据库特征的变化而变化，并且在更改为不同版本的neo4j时也会发生变化。

否，您无法将密码转换为大O符号

Cypher没有描述如何获取信息，只描述您想要返回的信息类型。Neo4j数据库中的Cypher planner负责将一个Cypher转换为一个可执行查询（使用关于它必须查找哪些信息、哪些索引可用以及关于被查询数据集的内部统计信息的启发式方法。因此，只需更改数据库的状态就可以改变Cypher的复杂性。）

一个非常简单的例子是Cypher

Cypher 3.1匹配（A{id:1}）-[*0..25]>（b）返回不同的b

。使用具有周期的相当平均的连通图，运行Neo4j 3.1.1会因为太复杂而超时（因为规划人员试图找到所有路径，即使它不需要冗余信息），而Neo4j 3.2.3会很快返回（因为规划器认识到，它只需要像深度优先搜索一样进行图形扫描即可找到所有连接的节点）

---

旁注，您可以主张在返回结果上使用大O符号。例如

MATCH（a）、（b）

的最小复杂度必须为n^2，因为结果是笛卡尔积，执行的复杂度不能低于答案。了解复杂度如何影响行数可以帮助您编写密码，从而减少计划员最终计划的工作量

例如，使用带有COLLECT（n）的

作为数据匹配（c:M）

来减少计划者在下一部分密码之前完成工作的行数，从nm（第一次匹配计数乘以第二次匹配计数）减少到M（1乘以第二次匹配计数）

---

但是，由于Cypher没有承诺如何找到数据，因此无法保证执行的复杂性。我们只能尝试编写更有可能获得最佳执行计划的Cypher，并使用EXPLAIN/PROFILE来评估计划者是否能够找到相对最佳的解决方案。

这类问题都是不可能的随时可用。但是可以通过一些额外的努力来推导/近似

在分析查询时，我们会得到一个函数列表，neo4j将运行这些函数以获得所需的结果。 理论上，每个函数都与从最坏到最好的复杂情况相关联。其中一些函数也将并行运行。这将影响运行时，具体取决于服务器的核心

例如，match（a:a）match（a:B）产生笛卡尔积，这将是O（count（a）*count（B））

类似地，查询计划中的每个函数都有这样的时间复杂性

因此，这些函数的时间复杂度的聚合将为您提供查询的时间复杂度的总体近似值

但每一个版本的neo4j都会时不时地改变这一点，因为它们总是可以改变查询的植入，或者实现更好的运行时/结构更改/并行化/更少的ram使用

如果您正在寻找的是neo4j查询优化的迹象，那么db hits是一个很好的指标