compaction后会释放空间
建议使用分区表，卸载可以只需要删除分区，业务使用的华需要包含分区键，才能分区剪裁
目前我们遇到一个场景，也是分区表的一个弊端：DML查询请求A分区执行时间比较长【几十秒】，在发起DDL删除分区的操作，这个场景可能会遇到waiting get meta lock很久，如果业务链接比较多会导致链接打满，影响业务
gc 之后释放，没有碎片
这个不只是分区表的弊端吧，正常的表当前有dml在执行，如果再发起ddl的话，ddl需要获取元数据锁，会等待dml执行完，正常的表也会遇到呢
是的，单表也会遇到，所以如果采用按照日期分表，每天，或者每月一张表保存，这个问题就规避掉了
这样确实能规避，就是使用比较麻烦，分区卸载的话，你们业务是什么样的，可以在凌晨3 4点的时候基本没有业务的时候删是不是也就规避了
我们不用分区表，因为基于RANGE的分区表还有热点问题，基本都是创建1024个单张物理表
1 个赞
比较赞同你们这种做法
这样相对来说比较麻烦，有啥心得可以分享下
delete 的操作，等待gc时间，会自动释放空间，但是从删除完毕到释放空间的时间可能会有点长，这个只需要等待就可以的，建议分批进行删除
业务代码里增加个获取分表号的函数，每次操作表前调用下，partition_key为整型，采用HASH算法，以python为例：
def Get_Real_Table(partition_key):
tab_num = partition_key % 1024
return (“table_name_%s” % (tab_num))
delete释放很慢，还是用分区表吧
gc会释放磁盘碎片
delete时不会真的删除，只是打上删除标记，等后台在compaction的时候会清理掉这些delete的数据，并合并底层数据文件。所以理论上是没有磁盘碎片的。
不会，他会自己清理的
我想了想，tidb底层的rockesdb是kv数据库,所谓的碎片这里可以理解为没用的key，这样的话还是有的
应该会有，只是多与少。