MySQL表历史数据清理总结

最近工作中在处理线上几个数据表的清理工作，工作虽然简单，但操作起来注意的地方还是挺多的。现将整个过程进行简单的总结，以便作为日后的参考。

首先确定下我们清理数据的期望：

对于待清理的历史数据可分为两类，一类是确认没有实际价值的数据，这部分数据可以直接删除，采用定时器的方式定时清理就可以了；另一类的是未来可能有价值的数据，这部分数据一般不会直接删除，而是定时将历史业务数据的归档。

针对第一类数据，定时清理比较简单，只需要在低峰期定时按条件删除即可

在实际工程实践中，可能大部分还是第二类数据，定时归档数据，这里主要需要考虑数据迁移的时间，是否能够用上索引等问题。这部分暂且不表，等后面实际操作了再结合一个案例进行说明。

当然如果前期已经考虑了数据清理的方案，一切都会比较简单，表不会变得很大，也没有没有在大表中删除数据的需求。但是如果和我们一样，是等到数据量堆积很大了才着手考虑清理，就会遇到在一张在线业务大表中，删除大量历史数据的情况。接下来就对遇到的这种情况进行总结，网上查找的资料，方式主要有两种。

按一定的查询条件，分批次的删除数据，该方法操作比较简单，但需要注意的地方也比较多

注意点：

实测中，删除 1400w 数据，日志空间增长近10G，与删除数据占用存储空间接近

实际操作中注意以下几点：

我们线上有个任务表 t_task，目前数据量在 2000w ，存储空间在 18G 。计划先将 2 个月以前的数据进行清理，在清理历史数据后再考虑分月归档。

表的 create_time 字段没有索引，主键 ID 采用雪花算法生成。因为表中数据最近数据为热点数据，所有没有采用方案(二)，使用的是分批删除的方式。

在实测中发现，分批删除如果根据创建时间做查询删除，耗时不太理想，需要选择在低峰段进行。考虑到我们的数据表主键是趋势递增的，我们可以批量删除前 50w 条数据，直到第50w条记录超出了需要清理的日期，然后再手动将剩余的一小部分数据删除(如果不要求特别精确，其实也可以不删)。实际测试中，采用这种方式每执行一次大约 10s 左右。这样做的好处是耗时短，可以在任意时间段进行，不好的地方是，最后还是需要手动做一次清理。