【 TiDB 使用环境】
阿里云ECS实例上部署安装的环境。
【TiDB 版本】
v2.1.0 (生产环境，暂时不考虑升级)
【概述】 场景 + 问题概述
现在要对Tidb，Tikv服务器进行缩容。
所以想先腾出各台服务器上的磁盘空间。
于是对数据库中各表的数据进行删除。
但在累积删了将近5亿条数据之后，从监控上看到的StoreSize并没有什么明显的变化。（删除数据后已发生过多次GC。）
配置基本没有改过，只是调整了tikv_gc_life_time时间从原先默认的720h调整成了12h。
网上看到有人说truncate和drop表之后，在进行GC后才会释放空间。delete并不会。
想问：
有人通过delete表数据的方式释放磁盘空间的么？具体是怎么样的一个步骤？
如果无法通过delete数据释放空间，有别的方案么？（现有表中的数据依然需要，可以根据一些where条件删除不需要的数据。）
delete 表操作以后，需要等 GC compaction 释放空间，这个不需要额外的手工操作；
可以试试用 tikv-ctl 在没给节点做一下 compaction操作，可以参考一下官方文档。
好的 感谢。
由于我们这个版本是2.0.1的，好像没有tikv-ctl。
该怎么在tikv上执行compaction操作呢？谢谢
你好，我这边试着下载了 tidb-v2.0.1-linux-amd64.tar.gz，里面有 tikv-ctl 管理工具。下载链接如下：（你帖子最上面说的是 v2.1.0 ，如果你要下载这个版本的工具，将链接的版本替换掉即可）
https://download.pingcap.org/tidb-v2.0.1-linux-amd64.tar.gz
tikv-ctl 旧版本使用链接，请参考 https://docs.pingcap.com/zh/tidb/v2.1/tikv-control 。希望对你有用！
非常感谢，这就去试试。
您客气了
单个做意义不大吧，毕竟不确定删除的空间是否在这个tikv上。
搜了一下类似主题，发现drop和delete差距好大。看文章的内容，即使compact之后，还会有12%的冗余数据，惊呆了……
如何高效地回收磁盘空间
- 为什么我执行了
DELETE FROM table_xx;后磁盘空间迟迟没有回收？（监控上显示的磁盘剩余空间并没有增大）参考上文中对 GC 的解释，TiDB 删除数据也是为其增加一个特殊的新版本，旧版本要等待至少 10 分钟后才会真正从 RocksDB 中删除，而 RocksDB 回收物理空间还需要更多的额外时间。因此我们建议用户如果要删除某个表的数据尽量使用
DROP TABLE table_xxx，而不是DELETE FROM table_xx。 前者会在超过 GC 时间后，直接删除 RocksDB 在磁盘上的物理文件。
- TiDB 旧版本数据过期时间是可配置的吗？应该如何调整这个配置的大小？
可以通过 MySQL 客户端连接 TiDB，查看 TiDB 的系统表
SELECT * from mysql.tidb，tikv_gc_life_time即为旧版本的过期时间， 用户可以动态调整该配置，但是 TiDB 不允许该配置的值低于 10 分钟，更低的值将被忽略。建议用户不要把这个值设置得过大，以免浪费更多的磁盘空间， 同时还可能因积累旧版本数据过多，导致 GC 流量过大影响了其他业务。
- GC 删除数据所占据的物理空间能在 RocksDB 中被立刻回收吗？
GC 删除的数据会很快被 compact 到下一层。在 TiKV 的 CPU 资源充足，RocksDB compact 足够及时的情况下，由于相同层内不会有 重复数据，因此最多存在 12% 应该被删除的重复无效数据，这是由于 rocksdb 的写放大带来的数据。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。
