nebula版本：3.5，cpu:4，内存：8G，硬盘 100G
查询语句：
查询耗时：
执行计划：
result.csv (12.0 KB)
result.csv (12.0 KB)
贴一下在群里的第一个回复哈
这里贵在起点的查询，可能的优化方向
- 让包含测试组信息被组织为单独属性，对它做索引
- 让测试组信息成为某一个属性的前缀神，对这个属性做索引
- 把测试组作为单独 tag，对这个 tag做索引
只要是能提供的其他细节优化表达比如
- 边的方向确定的话，给出方向
- 如 @方扬 哥提到v2 的 tag 等等
关于语句的调优，cost 分析可以参考 https://www.siwei.io/ngql-execution-plan/
2 个赞
分享执行计划的格式，推荐参考
哈
usr_grp 的 schema 能否发一下，name 的类型是 string 类型还是 fixed_string 类型，这个字段是否有索引
LOOKUP ON usr_grp
WHERE usr_grp.name contains "测试组"
YIELD id(vertex) as usr_grp_id |
GO FROM $-.usr_grp_id OVER * BIDIRECT
WHERE "usr" in labels($$)
YIELD $$ as v
2 个赞
这种写法得全文索引
我这是通过studio可视化控制台打印的
你贴的是 explain 不是 profile 吧？贴一个 profile 的再？
profie我怎么发你呢
还发 csv 附件就行哈，我发现用 excel 之类的看也挺清楚
可以编辑贴在一楼
好的
profile数据没了？大家应该想看看查询的时延。
1 个赞
你这个 CSV Profile没有 profiling data 这一列。。。看不到扫描的数据量和耗费时间，建议按照前边提到的，用 console。
- IndexScan 这一步是起点搜索，csv 里没有 profile 数据，看不到数据量，但是可以判断是索引全扫描的，这个就和数据总量有关了。这是一个非图的查询
没有 columnHint，没有 filter，是全量数据扫描
-
Traverse 这一步没有指定 e 的类型，这里可以看到你的 edge type 是不少的，如果有这个信息，也可以填上
-
Traverse 的方向如果有也可以填上箭头
总体来说建议还是我前边二楼说的。
或者，如果现有的 schema 之下，用 contains 做为起点搜索（这是非常不图的查询），按照 @ianhe 的建议，用 fulltext search 接 GO 查询。
1 个赞
主要我们这就是返推的逻辑，不一定会固定哪个边
这里应该是涉及到走对侧类查询了，主要是3.5版本lookup感觉有点限制条件太多，where字句只能有一个条件，第二查询列还不能为null
可以用管道，之前好像讨论过，第一跳用 contains，第二跳再 WHERE 进一步过滤，想怎么过滤就怎么过滤
这样跳的就慢了
就是为啥match这种查询会慢呢