提问参考模版：
复核索引创建(id、name、age、sex、hobby)和（id、name、sex）使用内存差别大吗？
不大, 数据会膨胀, 内存几乎没区别
如果新添加age用于多条件查询，对于复核索引(id、name、sex)只能删掉索引，再创建(age、sex)?
不用, 直接新建即可
主要想了解(id、name、age、sex、hobby)全字段索引和（id、name、sex）部分字段索引差别，
规则是尝试新建的索引, 如果与已有索引的结果相同, 就不允许建新的.
比如您已经用 第 1,2,3,4,5 个字段建索引了,
那么下面 4 中索引是不允许建的, 即第 1,2,3,4 个字段 / 第1,2,3个字段 / 第1,2个字段 / 第1个字段
但是 用第 1,2,4 个字段建索引是允许的
复合索引为(id、name、age、sex、hobby)，也能使用id、age、sex查询，
如果有10个字段，都要满足相互查询，那只能创建10个复合索引，按照每个字段往后依次把字段添进去？
在2000W的tag上创建单索引，drop后compact，物理空间多占用1-2G，
如果T+1更新，每次更新都需要重构索引，物理空间冗余会越来越多？
复合索引为(id、name、age、sex、hobby)，也能使用id、age、sex查询，
如果有10个字段，都要满足相互查询，那只能创建10个复合索引，按照每个字段往后依次把字段添进去？
您举得例子很有代表性, 用字段 1,2,3,4,5建索引 , 然后按字段1, 3, 4 查询, 索引是不生效的(只会对字段 1 生效).
(索引需要按照连续字段查找, 以本例来说, 索引可以对字段 1,2,3,4,5 / 1,2,3,4 / 1,2,3/ 1,2 和 1 五种组合生效)
理论上, 如果您想随意组合查询条件, 那么对于 n 个字段的 tag , 您需要建 2 的 n次方个索引,
这肯定不是您需要的. 所以还是得再考虑下业务.
在2000W的tag上创建单索引，drop后compact，物理空间多占用1-2G，
如果T+1更新，每次更新都需要重构索引，物理空间冗余会越来越多？
理论上索引在 drop & compact 之后不会有多余的空间. 您这个情况, 我个人怀疑可能是 nebula 的其它模块在导数据时留下的 WAL. 您这个数据是多久之前导的呢?
数据前几天导的，执行了第一次compact后是51G，重新创建索引，drop后再次compact是53G，3台服务器基本都是这个占用
几天的话应该不是 nebula 的 wal了, 不知道是不是 rocksdb 再搞事情. 您可以再关注下, 要持续, 大比例增长可能是哪里有 bug.
后面我注意看下，配置文件基本就改的端口
哦, 我之前说的那些都是针对 lookup, match 挑索引现在有个已知 bug, 有可能用不上后面的多级索引. 正在修.
后面索引会优化吗？
还有想问下look或者match语句支持这种吗？
a->b,a->c,a->d，同时满足b,c,d条件的a的点
如果a点是已知的，建议用fetch语句查询；如果a不是已知的，需要条件 b,c,d来过滤出a点的话，目前只能创建一个包含字段b,c,d的index。
浙ICP备20010487号
