看了下，是因为只有一个index文件，再加上频繁的delete操作，但是已经delete掉的数据的index没有清理，所以导致最后的index文件大小膨胀了？
升级的话我们需要内部评估下，2.5.20能解决这个问题吗
persistent_index.cpp:571，grep下这个关键字，看看最后的usage，有多少usage特别小的
类似这种
I0513 12:57:42.952131 16751 persistent_index.cpp:571] finish writing immutable index /data1/starrocks/be/storage/data/367/4836406/1889091023/index.l1.1843458.0.tmp #shard:32832 #kv:1841769 #moved:0(0) bytes:31272730624 usage:0.002
./meta_tool --operation=delete_persistent_index_meta --root_path=/path/to/storage/path --tablet_id=tabletid，升级前可以先停下BE，然后用这个命令把这个usage特别小的先临时处理下吧。后续还是考虑下升级解决吧
好的，这条命令是删除一些用的少的index是吗，停止BE执行命令然后再启动BE是吧。
对，这个只能暂时缓解下，后面可能还会出现。升级后在be.conf里加上enable_pindex_minor_compaction=true这个配置
小版本的升级能解决这个问题吗，比如升级到最新的2.5.20。
或者你可以先用alter table xxx set (“enable_persistent_index” = “false”)先临时关闭这张表的持久化索引。可以先在这个版本上规避这个问题，后面等你们评估结束后再操作升级。这张表总行数不多，对内存压力很小，可以作为这个版本上的一个临时解决方案。
好的，这个方式可以，我们先试试。直接alter table修改enable_persistent_index，会对现有的业务查询有影响吗？
不会，修改完可以show create table看下。
好的。
是1个新问题，2.5.21会Fix这个问题，等升级到2.5.21后，再把persistent index打开。