【 TiDB 使用环境】生产
【 TiDB 版本】v7.5.1,v7.5.4
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
感觉roksdb这个mvcc版本这块还是有点未知bug,我这个表4000多万行，全部key竟然有6亿多个，通过下图可以看到行数，并且有正常gc,compact filter可以解决这个问题，但是按理说我7.5.1版本，应该已经解决了compact filter的bug了
通过tikv-ctl可以查看，对应的region有gc之前的时间，所以比较诡异
region-compact-min-redundant-rows 和比例 region-compact-redundant-rows-percent 自动触发 compaction，从而提高 Compaction Filter 的 GC 速度。因此，在 v7.1.3 及之后的版本中，如果遇到上述情况，建议调整这两个参数，无需关闭 Compaction Filter。没用，我6亿个key远远超过这个阈值了，但参数我也没调，后续我再测试看看
后续调整后怎么样了
第一步调整：
set config tikv raftstore.region-compact-redundant-rows-percent=5;
set config tikv raftstore.region-compact-check-step=10000;
没有效果
第二步调整：
set config tikv raftstore.region-compact-check-interval=‘1m’;
set config tikv raftstore.region-compact-min-redundant-rows=10000;
有些效果，但是最终在57457191的key上停止了
尝试关闭filter
set config tikv gc.enable-compaction-filter = false;
show config where type = ‘tikv’ and name like ‘%enable-compaction-filter%’;
key的数量确实没有变化
但是关闭filter之后可以看到gc的时间有明显的升高
我以前测试清理是很不积极的，一张表一亿数据delete掉，几天才能清理完
对，这个compact的机制还是有些慢的
个人理解这个测试可以说明2个问题：
1，region-compact-min-redundant-rows比region-compact-redundant-rows-percent效果要直观一些。碰上类似情况可以优先调整这个参数。
2，gc.enable-compaction-filter = false 这个回收方法在7.1版本以上(注意子版本号要包含这个issue compaction: consider redundant mvcc.delete rows to trigger Rocksdb compaction · Issue #17269 · tikv/tikv · GitHub ，不然还是不能回收)，确实是提升不大了。gc时间还变长了。
是很意义的测试。 
