有这样一个场景，TiDB的数据是从其它MySQL同步过来的，或者的合并汇总到一起（比如分库，分表）等场景，在TiDB会做一些统计查询，只需要在TiDB保留最近一段时间的数据即可，其它数据使用pt-archiver purge处理掉。
存在的问题：
1.清除的数据不释放磁盘空间
2.select min(id)巨慢等问题
建议改进：
1.GC检查region里的数据如果都已经被删除掉了，则删除region
2.如果delete是覆盖整个region则删除整个region
3.对min/max作优化，在每个region里最大值和最小值，在表元数据里最大值和最小值的region id
select min(id) 这个id是主键吗，不应该很慢吧
1.看下max-merge-region-size"和"max-merge-region-keys”这两个值的设置，正常tidb中如果有region符合条件的话，会自动merge region，释放空间
2.id上如果有索引或者时主键的话，min(id)很快，如果没有索引的话，tidb底层存储时key value结构，每个region上的id并不是由大到小存储的，所以获取最小值必须全扫描region。。。。
以下是我的个人想法：
问题：
1、因为存在MVCC，删除并不会真正删除，需要等待GC，而底层RocksDB也需要compation才能真正释放数据
2、因为扫了大量gc的数据，把gc时间调短，或换种删除数据的方式（truncate partition）
建议：
1、region只是逻辑概念，删除region会造成空洞，所以还是得merge才能变少
2、region只是逻辑概念，我想你说的是删除底层对应的sst，但是我觉得如何判断这个region底层的sst需要全部删除是个问题，drop table、truncate table这种操作对应的是一段key范围，可以对应到region上，并且这段范围不会再写入数据了，等gc就可以直接删底层sst，但是delete不一定是对应一段key范围，region为空的条件是什么时间判断的呢，那这个region后边有插入了怎么办呢？
3、region这个逻辑概念不知道能不能存最大值最小值，存的时候是存在那里，存哪列的最大值最小值，存哪个mvcc版本的最大值最小值；表元数据里存最大值最小值的region id这个不需要吧，通过索引查询最大值最小值，PD会告诉你找哪个region吧
1 个赞
清除数据可以释放磁盘空间的，只是需要等GC
gc_file_time调时间，默认是10分钟，建议确保有时时的pump或者br的情况下操作，select慢问题建议看下执行计划，是不是没有下推，或者kv资源本身被打满了。
等了一个月都没有释放，删除的数据不少，查表所在的region只多不少
delete不释放的
如果region的部分数据被delete，不释放可以理解，整个region都被删除了，还保留是为了什么
你的是什么版本？
我也遇到这种mvcc 版本不回收的情况(6.5.3版本)，最后调整一个参数就好了将 enable-compaction-filter 设置为false(这个可以在线调整，调整完这个参数可能需要等待1-2天)
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration#gc-in-compaction-filter-机制