【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.1
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
做一个测试 ，1000万条数据的表进行delete删除
所有数据删除，检查磁盘空间并没有释放,gc也是默认设置正常推进的。
问题是什么大概detele的数据多久regions会显示为空，多久会进行merge
把测试表数据delete全部清空，10个小时空间没有释放，regions都在
可以查下 GC 的配置情况，在进行排查
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration#gc-配置
GC 的执行过程可以参考下面的文档
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-overview#do-gc进行-gc-清理
如果数据已经删除，确定需要快速的GC 来释放，可以通过手动控制的方式来执行：
https://docs.pingcap.com/zh/tidb/stable/tikv-control#手动-compact-整个-tikv-集群的数据
gc参数都问题，你可以试试delete数据，regions空间占用不会释放的
region 的合并和配置，以及集群的调度速度有关系的
另外合并的配置没开启，就不会合并空的 region
gc_life_time 和 gc_run_interval ，并根据实际情况进行调整
合并的配置 默认是开启的，虽然数据全部delete了 如上图查询到的regions大小都高于合并触发条件20M
compact也试过了，没什么效果
合并的调度策略是可以调的，因为调度太频繁了会影响集群的性能，默认值会比较保守。
官方文档中也有一些介绍：
https://docs.pingcap.com/zh/tidb/stable/massive-regions-best-practices#方法五开启-region-merge
合并如果效果不佳，可以看下跨表合并的参数是否开启，参考下这篇文档：
用的7.1版本，跨表合并的参数都是开启的，测试比较简单，新建表插入大量数据，再循环delete全部删除，发现空间回收不了
这个讲的比较详细
对数据做删除操作之后，空间回收比较慢，如何处理?
TDB采用了多版本并发控制(MVCC )，为了使并发事务能查看到早期版本的数据，删除数据不会立即回收空间，而是推迟一段时间后再进行垃圾回收(GC)。
1）可以通过修改系统变量tidb_gc_life_time的值（默认值为10m0s）配置历史数据的保留时限。
2）可以设置并行GC，加抉对空间的回收速度。默认并发为1，最大可调整为 tikv实例数量的50%。可使用update mysql.tidb setVARIABLE_VALUE=3” where VARIABLE_NAME=“tikv_gc_concurrency”;命令来调整。
TiDB中删除数据后会立即释放空间吗?
DELETE，TRUNCATE和DROP都不会立即释放空间。对于TRUNCATE和DROP操作，在达到TiDB的GC (garbage collection)时间后(默认10分钟)，TIDB的GC机制会删除数据并释放空间。对于DELETE操作TiDB的GC机制会删除数据，但不会释放空间而是当后续数据写入RocksDB且进行compact时对空间重新利用。
数据删除最高效最快的方式?
在删除大量数据的时候，建议使用Delete from t where x limit 5000 (x.建议在满足业务过滤逻辑下，尽量加上强过滤索引列或者直接使用主键选定范围，如id >=5000n+m and id <= 5000(n+1)+m这样的方案，通过循环来删除，用Affected RowS ==0作为循环结束条件，这样避免遇到事务大小的限制。如果一次删除的数据量非常大，这种循环的方式会越来越慢，因为每次删除都是从前向后遍历，前面的删除之后，短时间内会残留不少删除标记（后续会被GC掉)，影响后面的Delete语句。如果有可能，建议把Where条件细化。
对于DELETE操作TiDB的GC机制会删除数据，但不会释放空间
也就是说DELETE操作后gc后也不会释放空间
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。