【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v7.5
【复现路径】我们有存储在tidb非常大的表几十亿笔吧，但是应用说只需要存储半年数据就可以了，我如果delete了话，不讨论慢不慢的问题，会不会有磁盘碎片，有没有类似经验，应该如何清理空间
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
没有磁盘碎片，会gc的时候整理磁盘
那空间会释放吗？
https://docs.pingcap.com/zh/tidb/stable/sql-statement-alter-table-compact#语法图
TiDB 存储节点在后台会自动发起数据整理（Compaction）。数据整理时，表中的物理数据会被重写，如清理已删除的数据、合并多版本数据等，从而可以获得更高的访问性能，并减少磁盘空间占用。使用 ALTER TABLE ... COMPACT 语句可以立即对指定的表进行数据整理，而无需等待后台触发。
该语句执行时不会阻塞现有 SQL 语句的执行或 TiDB 功能的使用，包括事务、DDL、GC 等，也不会改变通过 SQL 语句访问获得的数据内容。该语句执行时会消耗一定量的 IO 及 CPU 资源，请注意选择合适的时机执行，如资源空闲时段，避免对业务造成负面影响。
该语句会等待表中所有副本都数据整理完毕后才结束运行并返回。在执行过程中，你可以通过 KILL 语句安全地中断本张表的数据整理过程。中断不会破坏数据一致性或丢失数据，也不会影响后续重新发起或自动触发后台数据整理。
这几十亿是总数据量，还是半年的数据量？如果是总数据量，那半年数据量是多少？
如果半年数据量比较少，是不是可以通过建新表，迁移半年数据，然后rename table的方式替换表就可以？
1 个赞
底层是leveldb，删除数据的时候可能会有碎片，但是leveldb会进行compaction，这个过程将多个小文件合并成较大的文件，并回收未使用的空间。这个过程有助于减少磁盘碎片，提高存储效率。
半年就是几十亿，通过迁移半年的数据归档不太现实
1.那compaction后，空间使用率会自动降低吗？还是不降低，但是合并的空间我可以再次使用？
2.我这种大表适合delete的方式清理，还是分区表解决呢，使用分区表有要求where条件需要包含分区键吗？
谢谢回复
delete操作最终会释放空间，做就行了 
delete以后，gc时间到了就会清理mvcc版本了，空间也会释放出来。
你这种需要清理历史数据的，典型的分区表使用场景，过期的时候直接drop partition就行了
其他正常使用时，如果条件能包含分区字段最好，不能包含的时候只能所有分区都扫一遍，比你在一张表中这个分区字段没有索引稍差一点
gc会解决
TIDB的方式是使用的LSMTREE，数据一直增量中，GC清理过期数据，这个不存在碎片的说法
删除操作只是做个删除标记，通过 gc 定期清理过期数据。会进行compaction，这个过程将多个小文件合并成较大的文件，减少碎片.这样？
会很缓慢的释放，而且也不能全部释放，如果要加速释放要手工compact，资源消耗极大
几十亿你还是分区表吧，drop分区就一秒。
delete操作先gc,gc是这样：
硬盘有一堆sst文件，存着key-value的排序好的数据。delete实际上是又写了新的key-value进去，然后gc把这些没用的key-value标记为删除。
compaction操作是对sst文件进行重新排序，压缩，其中标记为删除的数据就不要了，然后生成新的sst文件，删除旧的sst文件。
gc不能释放，compact释放磁盘空间很慢，资源消耗特别大，要归并排序的
会释放，建议用分区表
不会的，底层是ROCKSDB引擎，有自动COMPACTION的机制，只要线上持续有写入，空间也会跟着降低
可以考虑创建分区，后期直接删除分区