目前有3个大表 30亿数据，4T大小。要删除历史数据。估计要删2T左右
我是按照月来分隔每次删除1w，写成批量sql然后用sh执行
DELETE FROM details_report WHERE receive_dt >= '20201101000000' AND receive_dt <= '20201130235959' LIMIT 10000;
但是这个时间比较长，删除的表大小都有记录。表1T以内的基本上都是10-40s删除1w数据执行完1条sql。
表2T 以上的都要1-2分钟。这个删除1w条时间目前看来确实是根据表大小增长。有没有什么加快的方法
v4版本，我们当时是搞的新建表，然后向新表插入，最后drop老表的方式。直接写sql比较慢，当时用了kettle这种etl工具，插入的时候分了5个线程，基本每秒上万条记录。
我上个月也这么操作过一张表然后truncate了15t数据，不过数据是通过dumpling导出到新表的。
我可能还不能用这种分5个线程的，这个服务器呀压力很大，有3个其他业务库在通过DM同步过来，我最多2个sh脚本同时执行。而且下班高峰还要停，否则DM同步就延迟 
如果在搞一个表插入，可能也不太行。现在是要收缩资源，在搞一个表就算暂时1年，可能都要1T吧。服务器空间收缩的每台服务器都90%了。现在就是想着删除历史数据，减少磁盘使用，然后在缩减TIKV服务器呢。
truncate不行，v4得drop 
你们这个太极限了，那只能满满删了，版本低，闪转腾挪的空间就小了。
我也想过这个方法，但是需要本地磁盘空间足够，我怕空间撑爆了。磁盘1.7T 基本上每个磁盘都用到1.5 1.6了。
而且这个表是实时业务表不能停，如果这么操作还必须找个时间点
对。删了几个月了。总使用空间少了800G了
20240517 38.8T
20240812 38T
所以现在想看看有没有什么方法，能够delete删除的速度快一点。之前删除七八百G的数据每小时删除两三百万，现在剩下三个2T以上的，每小时只能删除90w左右
实时表啊，那还是慢工出细活吧，别搞花哨操作加速了。
也可能是GC在拖慢速度，可以观察一下GC的进度。
升级提了几个月。没效果，只要业务不影响，上面领导就不会让动
4也太老了，性能差很多，还有很多bug
不要用limit删除，要删除快，你只能通过主键范围筛选，然后拆分成很多sql执行.
limit越删除越慢
删了几个月。差不多都是2分钟删除1w数据，通过主键删还得把主键找出来。又是一套麻烦流程
对呀。太low了。好几年前建的。而且还是2.0版本升上来的。
想办法去掉limit，用了limit就有性能问题
可以改成24h，不过缺点就是触发gc的时候，可能性能会有抖动，v4的性能略差一点。
我测了一下，改成1天和30天 ，时间都一样。
