【详述】开启持久化索引后，做数据导入验证，停止导入一段时间后，发现持久化索引的目录一直进行compaction操作，然后数据文件在更新，持久化索引也是不断更新。关闭持久化话索引，该表依然compaction。
【StarRocks版本】 2.3.4
【集群规模】测试环境，1fe 1be
【机器信息】CPU虚拟核/内存/网卡，例如：16C/64G/万兆
【附件】
是的，关注一下CPU，磁盘IO，没有造成大的影响就ok了。
这是特性引起的呢，因为我就发现了一个表是这样的。
主键模型会一直后台发起任务更新数据的。
抱歉，你说的话有点超乎我的认知，毕竟我没有想到任何理由，在数据没有更新导入变化的情况，数据存储文件有什么理由一直在变更，这不是无效的IO吗？ 或者能告诉我是代码的哪段逻辑？
我看了下这块代码，帮忙看下我的理解对不对呢？
所有的compaction 都是根据tablet 的compaction_score去选择besttablet去执行合并, 而 主键表的tablet score 感觉有点奇怪，等于
score = rowsetscore1 + 。。。rowsetscore_n
rowsetscore = _compaction_cost_seek + (cost_record_read + cost_record_write) * delete_bytes -
cost_record_write * stats->byte_size;
如下这一个tablet下，所有的rowset，以及它对应的score
然后be选它进行 compaction
而由于如下 这两个限制compaction之后结果大小的行为在
static const size_t compaction_result_bytes_threashold = 1000000000;
static const size_t compaction_result_rows_threashold = 10000000;
就会使得只会选择那个18268rowset（因为它最够大 1kw+），然后就一直循环去做这一个tablet的compaction ，而且如果有持久化索引也会跟着进行，并且由于他们整体rowset的score 比较大，导致会影响到其他tablet的updatecompaction，必须等到有很多rowset之后才会进行。
I1202 17:49:12.172003 2114532 tablet_manager.cpp:640] Found the best tablet to compact. compaction_type=update tablet_id=1548404 highest_score=230580601
主键模型因为要较实时更新最新的数据，在数据写入或查询都会触发数据更新操作，另一个是数据合并的操作，与更新最新数据无关，这个是批量操作，等到一定的rowsets再进行数据合并，合成更大的rowset。
您微信关注我们公众号，上面很多技术文章分享
- 我一直关注你们的微信公众号，但没有文章是讲合并选取tablet的策略的
2.我觉得您理解错我的意思：
“等到一定的rowsets在进行数据合并” 只是一个大的策略，具体实现是通过计算每个tablet它去做compaction的收益，也就是代码里的compaction_score， 而主键表的compaction_score的计算方式和其他模型是不一样的。 而我和你讨论的是主键表合并操作 选择tablet的策略。
因为我这个帖子发现的问题是：在数据没有写入没有查询的情况下，依然会选择某个主键表的tablet进行合并操作。