大家好, 我这有go和match 两种写法, 为啥结果不一样呢??? go的话, 默认就是出向, match的话,我都是加了方向, 为啥结果就不一样呢???
第一个的VID 是不是第二个里面的n.pid呢？
我测试了2 step的情况。发现是没有问题
go 2 step from ‘10400’ over * | YIELD count(*) as ct
77388 执行时间消耗 1.351761 (s)
match (n:Person) → () -->(m) where id(n)== ‘10400’ return count(m) as nct;
77388 执行时间消耗 10.315324 (s)
令我震惊的是 match的执行时间这么长 .
而且match (n:Person) → () → () -->(m) where id(n)== ‘10400’ return count(m) as nct; 一直会报错 network error 估计得调优
1 个赞
可以看到从4 steps开始就已经不一样了, 我是没搞明白, 对了, 我这份数据就1个tag 1个edge, 所以加不加关系标签都不所谓
请问可以公布一下你用的数据集吗？
下载地址可以发一下吗，我本地也测试一下超级节点的场景。
这个我就不知道在外网哪里下载了, 这是公司内部的测试数据, , 公司有规定, 肯定数据出不去的 
我觉得, 应该是有多跳节点数据的都能重现这个现象吧
go和match的语义并不是等价的，match会去除循环遍历，go不会对环做特殊处理。
2 个赞
你好, HG,
- 我还是没理解, 你既然说match去除环循环的边了, 那为啥match的结果数比go from 多呢???
- 还有你说的go语句没特殊处理是包括环遍历吗???
- 不知道你对neo4j了解吗??? 经过我的实测Nebula 和 neo4j的match 查询结果是一致的, 这个没问题,但是neo4j里面也有去除环遍历的多跳查询方法(apoc) , 他这个查询结果又和Nebula的go查的多跳结果不一样, 然后就搞得我很懵
- 还有这个K阶邻居就是用go语句查吧??? 你明白我的意思吗???
应该不是环的问题，match和go还有一个区别就是，match扩展的是路径，go只是终点的扩展，所以match在扩展的同时会join当前的起点和之前的终点，这样一整条独立的路径产生一个结果，而go则是一个独立的扩展产生一个结果
1 个赞