图数据库中有A/B/C/D三类TAG，关系为 A->B->C-D， 目前一个A节点有2000条关系，一个B节点也有2000条关系，一个C节点有2000条关系，现在用match查询，指定A的id，查询其3跳关系，要求末端的D需要满足name=‘‘xx’’,查询语句如下：
MATCH p1=(n1:A)-[r1:RA]-(n2:B)-[r2:RB]-(n3:C)-[r3:RC]-(n4:D)
WHERE id(n1) == 'aa'
AND n4.D.name =='test'
RETURN p1 LIMIT 200
该查询耗时在10s以上，这种查询有没有优化方法
opencypher 的过滤现在好像没有下推，目前大数据量，这种写法耗时会要很久
请问下有没有更好的查询方法呢
你最后的结果是要什么，做啥用的，可视化吗？是要点还是要边还是要路径？
另外，方向建议加下。
最后是要路径，这个查询最后想要实现一个节点推荐，需要路径做推荐的依据，关系的话由于目前是当成无向图存储的，比如竞争关系这种，如果加方向的话，可能要存储2倍的关系，看通过增加关系数量来添加关系是会有优化效果
那就看下硬件资源配置，看哪里是瓶颈
CPU/内存/磁盘 IO/网路 IO 等
目前看并发查询场景下CPU是瓶颈，不过单个线程查询时，查询耗时也在几十秒，满足不了业务场景，现在有以下几个改进思路，看下是否可行
1、在关系上增加属性，在路径查找时，通过关系上的属性进行过滤，此时，两个点之间的关系要扩大10倍，比如A->B 由2000条增加到2万条，但是通过属性过滤后的边大概是500左右
2、 将四跳查询进行拆分，用with裁剪中间结果数量，这样会降低查询的召回率
请问下方法一是否有提速的可能，我看文档中说索引无法提高查询速度