- 需求原因 / 使用场景
1.针对动态的构建tag和edge，复合索引使用不友好；
2.针对多属性的tag和edge，没有从具体的点开始走，以属性查询为起点走或者终点的条件组合，复合索引的组合为笛卡尔集； - 需求描述
能够支持单个索引构建，多个条件的组合查询，并且跟字段顺序无关
没太理解你的需求，能描述一下“动态的构建tag和edge”的意思吗？
用户从关系数据库自定义选择表，选择需要映射的字段及选择需要的字段构建索引，nebula全部后台自动化操作，不用手动操作nebula
我理解的是，从关系数据库中存储了tag或edge的元数据信息，无论用户选择哪些tag或edge的prop，需要nebula支持任意搭配的索引查询。是这样吗？
nebula查询必须建立索引。而将元数据转换后存储到nebula中，因为对条件的选择可能存在不确定性，或者条件顺序的不确定，希望能优化复合索引这块。对正常使用也一样，如果需要对一条关系指向中tag或edge添加条件，只要在单字段上添加了索引，能够支持条件组合查询。
你的需求我理解了。你的需求其实类似于关系数据库的索引逻辑。如果有索引，则通过规则寻找最优的索引，如果最优的索引不存在，则挑选一个次优的，如果实在没有有效的索引可用，则通过data scan进行查询。按照此逻辑，如果某个tag (c1, c2, c3…) 中对所有字段（c1, c2, c3）均创建一个索引，就能应付任何过滤条件的查询。即使没有创建index，也可以通过data scan进行查询。
这个功能目前还没有在开发计划上，主要原因有两点：1，这种查询在storage层很可能会导致 full index scan 或 full data scan，目前nebula还没有分页查询的功能，很难控制查询的时效性。2，nebula索引的根本目的，不是为了提高查询性能（和关系数据库有些区别，关系数据库的index是为了提高查询性能，即使没有index也能正常查询），而是为了解决通过prop过滤找到点或边的功能。
其实支持复合索引的功能，从编码的角度上来说并不难，只要在索引优化规则那里放宽索引选择的策略就可以了。
1 个赞
可以控制复合索引构建，提供给第三方使用者来说可能不友好。
现在版本复合索引a,b,c支持a==1 and c==1的索引，文档没有提及这个，后续版本希望保留这个，这个可以更少构建复合索引，节约物理空间。每多一个字段索引，使用的物理空间大概增加了单字段索引占用物理空间的一倍。后面希望索引这块可以更进一步的优化，提高操作性和体验。
想问下能不能查询tag或edge上有哪些索引？
目前看tag和index对应关系只能通过SHOW CREATE TAG INDEX语句来查询。
你这个需求很好，能否在github上开个issue，我们来支持一下。
例如语法： SHOW TAG | EDGE INDEXES BY name_lable
我去提个