第一种方案比较理想
建新的空表，然后做分区，这个方案我们已经试过了，我这边数据可能没有你的大，但是每天也有个千万数据，分区删除也快的。
1 个赞
我的理解方法1和2是对你这个场景都不行。原因如下：
TiDB对大事务有限制，最大大小10G
事务限制 | PingCAP 文档中心
大事务限制
基本原则是要限制事务的大小。TiDB 对单个事务的大小有限制，这层限制是在 KV 层面。反映在 SQL 层面的话，简单来说一行数据会映射为一个 KV entry，每多一个索引，也会增加一个 KV entry。所以这个限制反映在 SQL 层面是：
- 最大单行记录容量为 120MB（TiDB v5.0 及更高的版本可通过 tidb-server 配置项
performance.txn-entry-size-limit调整，低于 TiDB v5.0 的版本支持的单行容量为 6MB）。 -
支持的最大单个事务容量为 10GB（TiDB v4.0 及更高版本可通过 tidb-server 配置项
performance.txn-total-size-limit调整，低于 TiDB v4.0 的版本支持的最大单个事务容量为 100MB）。
另外注意，无论是大小限制还是行数限制，还要考虑事务执行过程中，TiDB 做编码以及事务额外 Key 的开销。在使用的时候，为了使性能达到最优，建议每 100 ～ 500 行写入一个事务。
建议使用非事务更新
非事务 DML 语句 | PingCAP 文档中心
使用场景
在大批量的数据处理场景，用户经常需要对一大批数据执行相同的操作。如果直接使用一个 SQL 语句执行操作，很可能导致事务大小超过限制，而大事务会明显影响执行性能。
批量数据处理操作往往和在线业务操作不具有时间或数据上的交集。没有并发操作时，隔离性是不必要的。如果将批量数据操作设计成幂等的，或者易于重试的，那么原子性也是不必要的。如果你的业务满足这两个条件，那么可以考虑使用非事务 DML 语句。
非事务 DML 语句用于在特定场景下绕过大事务的事务大小限制，用一条语句完成原本需要拆分成多个事务完成的任务，且执行效率更高，占用资源更少。
例如，对于一个删除过期数据的需求，在确保没有任何业务会访问过期数据时，适合使用非事务 DML 语句来提升删除性能。
1 个赞
选方案1，drop之前建议数据备份归档
你说的100-500写一个事务就是写一个commt提交吗
这个贴子还在呢？ 
感觉没有时间要求，还是慢慢delete吧，不然一下删太多，gc压力太大
不管怎么样，都要分批，TIDB不大支持太多数据一次性删除
倒不用这个小，万级应该不成问题
最好在半个月内，五六个T级别的，十几个几百G的。
对分批是肯定的，我是这么想的，delete 按照日期直接limit 10000，一次删除1w行。在业务低峰期操作。
tidb可以设置分区表吗。。。。 第一次听说。
周五快下班了发的帖子，周末休息就没看了。
gc时间不是10分钟吗，我写个脚本，一直删除1w行数据，一直执行，这样。超过10分钟，他会释放10分钟之前删除的数据占用的空间吧
兄弟，有sql能查看范围时间内的数据占用的空间大小吗，我刚来这个公司两三个月了，只知道这个表大概六七年了。占用4T，保留500天，具体有没有1T也不清楚。
我刚开始的想法是，创建一个空表。然后从365天前的那天数据，按天插入，在业务低峰期，一直插入
gc不是释放空间，compact才释放的，我的建议直接新建表（建成分区形式的），然后插入，插入完成老表直接drop，后续直接通过trunc分区来释放空间。
恩，我们老板关心的是哪个时间更快，空间释放更快。
我自己手动按天插入可以吗？
4.0应该是支持分区表的。