go 语句是否能够支持skip的功能？目前大概有140万的数据，在使用分页查询的过程中，后面几页的查询效率非常的低，是否能用skip跳过前面的部分，只查询该页的内容？
lookup on Claim yield id(vertex) as cliam_vid, timestamp(toString(Claim.accident_time)) as ac_time_1 skip 17000|
limit 17000, 18000 |
3.x 版本的分页这块没有做优化，都会把所有的数据获取回 graphd 在计算层做分页，没有在存储层直接 skip 相应的数据。所以理论上第一页和最后一页应该性能差距不会很大才对。
但是我这边测试下来的结果是后续的分页会包含前面分页的数据，例如说我查询（1000，2000）的数据时，其会包含（0，1000）的数据，相当于往后查询的时候会把前面查过的内容再做一遍，后续的效率相当低
lookup on Claim yield id(vertex) as cliam_vid, timestamp(toString(Claim.accident_time)) as ac_time_1| limit 17000, 18000 |
go from $-.cliam_vid over [edge_list] reversely yield $-.cliam_vid as claim_id_1, src(edge) as person_vid, $-.ac_time_1 as ac_time_1 |
go from $-.person_vid over [edge_list] where abs(timestamp(toString(properties($$).accident_time)) - $-.ac_time_1) <= 86400 and dst(edge) < $-.claim_id_1 yield dst(edge) as claim_id_2, $-.claim_id_1 as claim_id_1|
group by $-.claim_id_1 yield $-.claim_id_1 as src_v ,collect_set($-.claim_id_2) as dst_v
这是我的查询语句，是哪里出问题了呢？
上面测试的是 lookup+limit 的结果吗？
看了 lookup+limit 的执行计划，确实越到后面扫描 index 的条数越多。这里确实是个优化的点！
不知道这里的索引是按照什么字段建立的，如果是数值型的，可以考虑把 limit 转变成根据过滤手动分下区间，比如：
lookup on player yield player.name | limit 10, 20
转换为
lookup on player where player.age > 30 and player.age < 40 yield player.name
这里我们没法根据tag的属性去作筛选 
，因为这里是一定要过全量数据去找目标的，不分页的话直接查询就超时了，已经考虑在通过其他方法来进行优化了。
不过还是希望分页查询这块能优化一下，不然这样全部都处理的形式显然是不合理的
之前这里没做优化是想改 rpc 的模式为 streaming，那样就可以方便的控制 graph / storage 之间的数据流量。由于一些原因，这块暂时就没在做。
不过就这个 case 而言，直接是查询索引之后做分页是相对好做的，这块后续需要记个优化点。
cc @MuYi
问下，是只涉及到lookup + limit，还是都涉及
请问你们这边如果要把数据全部取出使用什么方案？我们这边也是碰到这个问题，我们数据比较大，每个tag可能超过1亿，使用skip翻到最后就卡死了
现在尝试了两种方法，一种是先花一定时间去检索全量的数据，将数据存在dataframe中，后续逐条遍历dataframe。单条检索的时间消耗在容忍范围之内。还有一种是想办法绕过该大规模的tag，从别的tag利用边过去，同时也能起到一定的筛选效果。还有一种我们这里使用结点的某一个属性datetime作为分页条件，可能通过修改条件来筛选，但是这个还没有测试，因为暂时对全量的数据时间范围不太清楚，还没法写具体的切分条件
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。