概述

如果大家需要定期去清理mysql数据库大表，可以参考以下杨大师的实现方案进行，建议先进行测试。下面以我的实际情况做一下实验演示。

前提：

1、数据类型为流水型业务，不涉及事务处理。

2、数据流程不会修改历史数据，仅参考近N天数据

3、操作时机不是业务高峰期

4、能够接受秒级的数据写入闪断。

思路

从处理方式来看，基本就是做了rename,把原来表的数据转置到一个中间库里面，然后补录数据，对于日志型的数据表来说是很有必要的。

要实现这个目标，我们需要尽可能保证中转表的数据要尽可能完整，而且要保证数据切换能够高效完成。

那么我们处理的思路就是增量迭代，即最后的切换阶段耗时最短，我们可以提前复制需要补录的数据，同时对当天的数据进行增量的补录，然后开始切换。

注意考虑主键自增的影响。

实现方式

1、创建同样结构的表，包括索引,一个表是做备份，一个是作为中转。

create table lcp_mq_record_arch like lcp_mq_record;create table lcp_mq_record_arch_new like lcp_mq_record;

说明：

create..as 用来创建相同表结构并复制源表数据。

create..like 用来创建完整表结构和全部索引。

2、需要把近一个月的数据表现存放到中转表log_new里面，为了提高效率，先保证当天的数据有效。

--当前时间大于11:00:00，但是间隔不大insert into lcp_mq_record_arch_new select * from lcp_mq_record where last_update_date between '2019-09-16' and '2019-09-19 11:00:00'; 

如果比较多数据，注意分段insert，完成增量数据的补录，直到增量数据的补录时长控制在秒级（数据集越小，处理时长越短）

3、切换表

RENAME TABLE lcp_mq_record TO lcp_mq_record_arch,lcp_mq_record_arch_new TO lcp_mq_record;

整个切换过程是很快的。

4、历史数据的补录

为了尽可能降低对线上环境的影响，我们需要缩小补录的时间范围，比如按照如下的方式来进行补录：

insert into lcp_mq_record select * from lcp_mq_record_arch where last_update_date>'2019-09-19 11:00:00';

因为结果集相对小一些，处理过程对已有的数据处理线程的效率影响最小，可以避免大结果集导致服务阻塞的情况。

当然关键的部分是整个流程梳理完善后固定下来，我们可以把它转换成一个脚本，这样后续的操作我们只需要输入表名，保留的时间范围即可完成这个看起来略微复杂的需求了。

觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~