我从具有 2 个可选路径的图表中选择数据时遇到问题。假设节点 A、B、C,其中 A 与 B 和 C 具有可选关系。
如果我查询
match (a:A) where a.xx = XX optional match (a:A)-->(b:B) return ...
或者
match (a:A) where a.xx = XX optional match (a:A)-->(c:C) return ...
一切都按预期工作。
如果我结合2:
match (a:A) where a.xx = XX
optional match (a:A)-->(b:B)
optional match (a:A)-->(c:C)
return ...
然后我只得到(经过长时间的查询)一个未知错误。
返回从 a,b,c 中选择属性,并使用限制来限制返回的数据量。是否不可能有多个可选匹配?
更新:
当我将查询更改为
match (a1:A) where a.xx = XX
optional match (a2:A)-->(b:B) where a2.uid = a1.uid
optional match (a3:A)-->(c:C) where a3.uid = a1.uid
return ...
如果 uid 是唯一的索引 id,则查询返回所需的结果。 但是它运行非常缓慢(如果 uid 是索引,则约为 60 秒,如果 uid 具有唯一约束,则约为 40 秒)
数据集并不是我所说的巨大:a 6500 、 b 86 和 c 90000 个条目。
最佳答案
假设你已经匹配了A
一次,你为什么要重新匹配它?
MATCH (a1:A) WHERE a.xx = XX
OPTIONAL MATCH (a2:A)-->(b:B) WHERE a2.uid = a1.uid
OPTIONAL MATCH (a3:A)-->(c:C) WHERE a3.uid = a1.uid
可以更好地表达:
MATCH (a:A) WHERE a.xx = XX
OPTIONAL MATCH (a)-->(b:B)
OPTIONAL MATCH (a)-->(c:C)
这看起来与您最初的示例非常接近,但没有理由让它表现不佳。如果您可以在关系匹配上放置一个类型,它会表现得更好:
MATCH (a:A) WHERE a.xx = XX
OPTIONAL MATCH (a)-[:REL]->(b:B)
OPTIONAL MATCH (a)-[:REL]->(c:C)
请注意,在将已绑定(bind)的节点带入 OPTIONAL MATCH 子句时,您不需要重新标记它们。
您应该对用于初始匹配的任何属性都有一个索引:
CREATE INDEX ON :A(xx)
您可以在 console 中尝试此操作看到它工作:
MATCH (n:Crew)
OPTIONAL MATCH (n)-[:KNOWS]-m
OPTIONAL MATCH (n)-[:LOVES]-t
RETURN n AS Neo,COLLECT(m) AS knows, COLLECT(t) AS loves
关于neo4j - 密码 2 中的多个 OPTIONAL MATCH 子句,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26480951/