为什么都是纯属性条件出发的查询，使用match耗时会比lookup久。

问答 问题
1

版本：3.4.0
部署方式：rpm
分布式部署

MATCH (v:entity) whrere v.entity.name > “kobe” RETURN v.entity.name limit 100;

LOOKUP ON entity WHERE entity.name > “kobe” YIELD entity.name as nam | limit 100;

使用match语句查询会超时，不会返回结果，并且会导致cpu飙升，虚拟机卡死。lookup会返回结果大概10来秒左右

是因为lookup直接通过index binary来匹配，而match是通过vid遍历吗？

2

你可以参考这个帖子 关于性能有调优的你应该知道的非技术姿势 把硬件信息和执行计划都贴一下。

3

MATCH 语句的profile弄不出来，只要一使用上述match语句就会卡住，explain可以

4

对对，执行出来可以用 profile，执行不出来用 explain。你两个都用 explain 看下执行计划。

5

抱歉 测试环境在内网 只能通过拍照

IMG_4455
IMG_44551280×960 123 KB

IMG_4456
IMG_44561280×960 125 KB

1 个赞
6

看执行计划，entity(name) 上没有建立索引，全表扫，然后进行过滤
match 慢的原因是 appendVertices这个算子 会将扫描到的点 构建vertex对象，然后过滤
lookup 是把 所有点和name扫出来，然后过滤，
可以profile看一下，appendvertices 时间占用多久

7

之前index是创建好的，后面测试的时候删掉了，现在我重建index并rebuild成功，还原之前的环境。

现象：match无法返回结果，会导致cpu飙升，虚拟机卡死。lookup可以返回结果

IMG_1676882345
IMG_16768823451280×863 106 KB

IMG_4457
IMG_44571280×960 142 KB

8

我看你扫出来的结果有1w 条， 按说用appendvertices 构造vertex 也绰绰有余， 你内存多大

9

每个虚拟机20G内存，主节点13g空闲 其他的两个节点也还是有几个G空闲内存

10

我用console 执行了，match语句匹配到了2千万条数据，为什么lookup匹配到10000条就不继续了 而match 却匹配2千万条？我只需要100条不应该是匹配了100条就结束吗？

11

lookup中 的 limit 下推到 存储层了， storage中每个分区只输出100， 总共1w个点， 然后在graph层再做一次limit 100.
match中的limit 没有下推到storage， 和优化规则有关

12

此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。