delete后续进行的compaction是系统自动进行的吗
有一点我觉得tidb可以改进下，比如用detele清空表，应该可以像truncate一样直接delete_range
这里面怎么执行的我没看过代码，不太清楚是不是有这个。
对，系统自动完成
搞定了吗
还可以测一下把gc调长一点，先不让它gc是不是空间会暴涨，中间的增大或减少，是不是因为delete的写入数据导致的
不让它gc是不是空间会暴涨, 这个以前测过，tidb删除数据就是插入条新数据
gc后空region就会合并，compact后合并sst文件释放空间
实践出真理！
gc 改小+ compact 不知道能不能对 mvcc 导致的select * limit 1 有效起作用
测试单机1tikv数据库，只有一张表 ，插入1亿数据进行每次10万条删除，可以看到sst文件在删除过程总和在变大或者变小反复，可以认为tikv在进行compact，compact会先建新文件然后删除旧文件，然后文件总体积就变化了。
后期经过手工compact，sst文件数量最后只剩下3个（可以认为tikv 有3个cf，所以至少3个sst文件）
这三个sst文件在手工几次compact后只剩下几百k
了解，这个系统自动触发的频率是多少
看来delete数据后，要多次手工compact后，空间会释放出来
不是必要的，自动compact也能释放，就是慢
请问如何找出哪些表有大量空region，而还未被系统回收的
空region数量在pd的监控那里能看到，但是对应哪些表的应该不好找。
我研究了下，可以这样查询，查到每个表的regions大小合计和数量，除一下就可以判断region平均大小，太小的肯定有未被回收的：
select DB_NAME,TABLE_NAME,sum(APPROXIMATE_SIZE),count(*) from
(
select t.DB_NAME,t.TABLE_NAME,region_id,t.APPROXIMATE_SIZE from information_schema.TIKV_REGION_STATUS t
group by t.DB_NAMe,t.TABLE_NAME,t.IS_INDEX,region_id,t.APPROXIMATE_SIZE
) a
group by DB_NAME,TABLE_NAME
order by 3 desc;
想知道哪个regions一条数据都没：
select * from INFORMATION_SCHEMA.TIKV_REGION_STATUS t
where t.APPROXIMATE_KEYS=0
GC只是在条目上增加删除标识，compact会压缩