https://nebula-graph.com.cn/posts/how-indexing-works-in-nebula-graph/ 这里讲到了索引的一些原理，但是我还有一些疑问：
lookup查询的时候 怎么和索引的kv存储联系起来？
比如 lookup on tag where tag.col1 ==1 # 使用的 index 是 index1，index1 on tag(col1)，
索引存储的时候key是（假定是顶点的属性索引）
在上边的例子中，是一个等价查询。这条数据在kv里边的存储结构为：
key : partId_IndexID_value(1)_vertexId
那么通过执行计划，发送到storage层的prefixScan的string为partId_IndexID_value(1)，这条数据被命中后，会通过解析这条数据得到相应的vertexID。
通过col1 怎么找到key里面的partid和indexId的呢？我知道 key里面的value(1) 是从col1转换而来
lookup是查所有partId，indexId通过query，能找到一个最优index，就有对应IndexId了
@critical27
这种方法 会遍历所有partid吗？效率高吗？
indexid 通过query？能找到最优的index 不理解什么意思？能举个例子吗？
我这个帖子的内容 可能会是 很多人关注的内容，也希望 这个疑问解答后 能完善官网现有的索引描述 @Amber
现在同一个vid的索引和数据是存在一起的，对写友好，但是读就得扫所有part。
比如tag有三个字段(c1, c2, c3), 建了几个索引(c1), (c2), (c1, c2), (c1, c2, c3).
lookup on tag where tag.c1 == 1的时候(c1), (c1, c2), (c1, c2, c3)这三种索引都可用
lookup on tag where tag.c1 == 1 and tag.c2 == 1的时候(c1, c2), (c1, c2, c3)比(c1)更好
lookup on tag where tag.c2 == 1的时候只有(c2)可用
联想到mysql的索引 加速查询，场景是读多写少，这个地方 nebula解决的场景问题是？
索引是为了加速查询的，nebula这种遍历 会增量 数倍的查询比较次数吧？（数倍是指 partid的个数）不知道我理解对不对，一起探讨一下，没有挑战的意识
理解的没问题，是所有partId都会读，可能会存在读放大比较严重的问题，但是比较次数是不变的，无非是在所有节点读出这批数据和在一个节点读出这批数据的区别。设计的时候主要是考虑，如果做全局index，那么就需要解决数据和index存在不同节点的问题，可能就需要引入事务（现在没做）。现在这个方案就相对简单一点，另外一个好处是，如果需要在lookup之后还需要读索引之外的字段，可以直接在本地拿。
我理解 这个方案 是目前的最优解，不排除后续改造升级的可能
是的 后面会考虑类似mysql索引的形式
