【详述】bloomfilter index创建以后性能达不到预期，创建index以后反而比不创建还慢，表大概200亿+，执行的查询语句达到分钟级别
【背景】做过哪些操作？
【业务影响】
【StarRocks版本】2.0.1
【集群规模】3fe+4be，分开部署
【机器信息】128C/512G/万兆 操作系统7.8
【附件】
create_table.sql 是表创建语句
before_index_profile 是创建索引前查询的profile
after_index_profile 是创建索引后查询的profile
query.sql 里面含有查询的语句以及创建索引的语句
您好，是否是高基数列？如果发现加了以后反而变慢了，可能是因为场景不合适
接近200亿+的总数量，查询的字段大概在1000w的不同值，应该属于高基数把
那bloomfilter和bitmap对应的场景应该是什么，官方文档标注的是高基数是bloomfilter，低基数是bitmap，我找了字段做同样的查询，这个字段100不到的不同值，创建bitmap index，效果依然不好
您好，我看过您发的profile了，加了索引以后确实是命中率索引的，耗时的话也可能是在建bloom filter的时候。建议您可以将imei这个字段作为duplicate key，且create时候尽量放在其他字段前面，我们的排序键也是可以加速查询的。
您好，您提出的这个解决方案我有些疑问，因为我们现在针对这张测试表，我们的诉求是大部分查询是查的msisdn，其他一些查询是别的字段，所以msisdn一定是排序建，但当查询非排序建字段的时候，给其他字段建立索引希望提升查询性能，当然创建物化视图用空间换时间也是可以的，但是这样的话，索引的目的是什么呢，或者说索引在什么场景下能提升性能呢
您好，麻烦再关注下这个问题，谢谢
您好，我们正在跟进这个问题，有了解决方案会及时回复您，请您关注一下论坛的消息。
您好，好的，谢谢~
可以加个微信15652918147聊一下，这个感觉有些不正常。
加你了，麻烦通过下，谢谢
楼主你好，这个问题最终解决方案是什么方便说一下么？
你好，和官方沟通了下，需要等官方的release，大体原因是因为索引扫描的时候次数过多导致，需要底层修改下扫描策略
好的，多谢~用法上没有问题就行
请问怎么判断是否是高基数列呢？基数指的是啥？
一个列不重复的值的个数就是这个列的基数。
你好，这个有计划在哪个版本优化呢
您好，有计划在什么版本优化呢