【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.6.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
做了一个测试，一个表有1亿数据我全delete了然后过了gc时间，再手工compact跑几遍，就从400个regions减少的1个了，磁盘空间到底释放了没有呢？
我的理解compact会重组新的sst文件，删除旧的sst文件，delete的数据在这个过程中就清理了，所以硬盘空间应该释放了，不知道理解的对不对
compact是会释放空间的
但是不能对tikv进行清理，只能清理tiflash
GC不会缩小SST文件，只是在条目上增加删除标识，磁盘空间不会释放。
Compact会将多个小 SST 文件合并为一个大 SST 文件并清理已删除的条目，磁盘空间会释放。
1 个赞
这个可以参考下
这样操作以后感觉是释放了的啊。实际是没释放吗？
gc后空region就会合并，compact后合并sst文件释放空间
region 不空的话，如果有比较多的deletekey，也能缩空间吧。
较多deletekey情况下不compact也缩不了空间
在 TiDB 中使用 DELETE ，TRUNCATE 和 DROP 语句删除数据都不会立即释放空间。
对于 TRUNCATE 和 DROP 操作，在达到 TiDB 的 GC时间后（默认 10 分钟），TiDB 的 GC 机制会删除数据并释放空间。
对于 DELETE 操作，TiDB 的 GC 机制会删除数据，但不会立即释放空间，而是等到后续进行 compaction 时释放空间。
目前不能针对单表的tikv进行compact，只能先查到表对应的region，然后对对应的region进行compact。
学习了，不能对tikv进行清理，只能清理tiflash
这里说的compact就是tikv的
compact 不需要手动处理，后台会自动执行的。
tidb自动执行的这种资源消耗很大的操作，触发条件很保守
可以自动也可以手动，紧急释放空间就需要手动，像@ zhanggame1说的自动触发条件很保守，你紧急清理数据重新导数没有空间你不能一直等着啊
现在磁盘不贵，我们TIDB集群没做过compact操作，不差那点空间 
不止说空间问题，无用空间不释放，sql执行是可能扫描到的，浪费大量io和时间
有写入就必须执行的。
既然谈到这里，我就再念叨几句compact的过程。
写入过程是这样的： 先写wal，然后写入memtable，也就是写入到内存。当这个memtable达到write_buffer_size后，转换成immutable memtable，还是在内存中。然后继续，直到memtable的数量到 max-write-buffer-number 个，触发flush写盘。
flush写入level0，当level0的个数达到 level0-file-num-compaction-trigger 个以后，触发 compact
从level0写入到level1
然后什么时候往下继续compact呢？
max-bytes-for-level-multiplier 这个参数控制着。
比如说 max-bytes-for-level-multiplier 这个参数是 10，level0 是1GB,那level1到达10GB就往下compact，level2 到达100GB就往下compact，level3到达1000GB就往下compact。tidb默认共6层。
所以这样看，删除个key，被compact的概率不大，所以不太容易缩空间，但是理论上是有机会自动compact下去的。
（后面的内容没仔细看代码验证过，只能大概认为是对的）
那么，为什么空region合并就缩空间比较快呢？
就是delete_range 了。空region直接执行 deletefileinrange，就把这个范围内的sst直接删掉了。