Nebula 版本 2.6.1
Studio 版本：3.0.0
nqQL语句如下：
match p=(:t_uid)-[e:e_order_pay{ptype:2}]->(:t_finger_id)
where e.ptype == 2
return p limit 1;
边e_order_pay，及变属性ptype均建立了索引：
create edge index ie_order_pay on e_order_pay();
create edge index ie_order_pay_ptype on e_order_pay(ptype);
该边的总量约有两亿行；无论把属性过滤放在where或者上面边定义的地方，整个查询均超时返回504
按照理解，索引应该是能生效的吧？ 我先创建的索引，再导入的数据
感谢感谢，那我资料贴全一些：
边及索引定义：
create edge IF NOT EXISTS e_order_pay(ptype int);
create edge index ie_order_pay on e_order_pay();
create edge index ie_order_pay_ptype on e_order_pay(ptype);
点和边数据量：
Tag t_uid 17302924
Tag t_finger_id 14613287
Edge e_order_pay 210707812
版本是2.6.1
三台Storage，三台meta，两台graph，
机器在k8s上：request 4cg8 limit 8c16g (最多8核16g)
磁盘是读写大概100M/s
执行计划：
之前运维升级过程遇到问题，所以回退版本了，
但是我觉得大概率和这个版本无关呢，因为我同时在用：nebula-explorer-2.2.0，在上面执行查询时一样的现象
11
索引已经生效了，可以看plan中的IndexScan算子；
但是你的数据索引的还是2亿，这里的limit下推还不支持，
感谢回复~！limit下推还不支持？？？
你的意思是limit不支持，所以由于返回的数据量太多才慢吗？
可是为什么会不支持limit呢？match语句后面return limit我试过是能支持的
是的，这个版本match是没有支持limit下推的
。文档上的 LIMIT 是用法层面的，你和 Shylock-Hg 讲的是具体实现层面的问题。
哦，所以我上面的语句用（ptype:2）筛选，是因为不支持limit，结果集包含太多数据才导致卡死吗？
另外，我司集群目前是机械硬盘，非常频繁地出现慢查询把graphd打挂的情况，比如这种case，我在所有的点和边都建立索引的情况下，每次查询必然导致graphd打挂：
match p=(v0:t_uid)-[*2…4]-(v1:t_uid)
where id(v0) == “610de551a4bb490001989e85” and id(v1) == “619b2a403d48e8000161d065”
return p;
可以用 profile <statement> 看每个算子的数据量
profile出不来，前面有explain的结果，你帮忙看看。
这个也explain一下
explain
match p=(v0:t_uid)-[*2…4]-(v1:t_uid)
where id(v0) == “610de551a4bb490001989e85” and id(v1) == “619b2a403d48e8000161d065”
return p;
如图所示，谢谢！
看上去是符合2.6.1的预期的，
要解决的话可以加内存，或者升级到更新版本（对match执行有做优化）
具体哪个版本支持match limit呢，另外由于目前是非ssd，可能影响也较大？
但是不至于每次查询能把graphd打挂吧。。。
你可以看看dmsg，确定一下是不是oom
