INDEX t_type ( f4 ) USING BITMAP
发日志吧， 减少点沟通成本
老师，不好意思，打扰您了，一个小时的日志大概有700多MB，我这边只能上传一小部分:partA_202408011800 (5 MB)
您之前提到可能跟建了bitmap索引有关，我看了下数据量比较大在1TB左右的那几张表都建了bitmap索引，但实际上建了bitmap索引的列只有两个枚举值，其他的表就是几个物化视图了。如果我直接drop掉bitmap索引，会影响性能吗
压缩下啊，压缩后会很小
好的，我重新上传了：be.INFO.log.20240804-060302-0630.zip (35.7 MB)
还有就是我发现关闭了swap内存后，相比之前打开swap内存compact的时间更长了，多了4-5个小时每天
不要开Swap
好的，谢谢老师，我先看看
我发现现在compact更频繁了，是针对之前那张表的一个同步物化视图一直在做压缩，今早差不多做了一个小时，磁盘IO一直100%
老师，我根据你的提醒，把我们的表没用的bitmap索引都删掉了，发现IO降下来了，我想知道有没有办法看到bitmap索引占的空间有多大，我发现删除bitmap索引的job都跑了好几个小时
这个功能正在研发中，不过有个比较麻烦的方法来看。
你微信号是啥，我想了解下什么样的Bitmap索引会产生这么大的IO压力。
我的微信号是LANCER_531，我再观察多几天，我发现今天下午本来定时做compact时磁盘写IO会升到100的现象没有出现了
有没有老哥知道这问题咋解决
哥们，解决了吗？也碰到这个问题了
我删除了多余的bitmap索引解决了一段时间的IO 100%问题了
公司里主要是有一些复杂的连表查询每天都在跑，所以IO持续一直高
这个主要的问题是这个表没分区，10T的数据compaction不可能很快的。应该做成分区表，历史数据尽量就不要变，这样只有最新分区的数据在compaction，这样io就轻松了。
主键表的更新是可以更新历史分区里的数据的，所以还是要分区，不要全量的不分区大表