如何优雅的实现DML批量操作（转载）
昨天处理了一个业务同学的数据需求，简单来说就是对一张大表做一下数据清理，数据量在8千万左右，需要保留近一个月的数据，大概是400万左右。
对于数据的删除处理，尤其是大表的处理，可以借助MySQL特有的一种处理策略，可以参考之前的文章:
从处理方式来看，基本就是做了rename,把原来表的数据转置到一个中间库里面，然后补录数据，对于日志型的数据表来说是很有必要的。
但是这种方式涉及几个细节，主要的出发点就是怎么样让这个操作更加可控，我所说的意思是整个处理过程你可以按部就班的操作，该备份备份，而补录补录，而对线上的切换过程都是毫秒级完成，几乎产生不了直接影响，要实现这个看似不大可能的需求，我们就需要设定几个边界：
1）数据类型为流水型业务，不涉及事务处理
2）数据流程不会修改历史数据，仅仅参考近N(可以为N,也可以为当天）的数据
3）操作的时机不是业务高峰期
4）能够接受秒级的数据写入闪断
明确了这些不能够之后，我们来看看怎么来实现这个目标，可以参考如下的流程图：
所以要实现这个目标，我们需要尽可能保证中转表的数据要尽可能完整，而且要保证数据切换能够高效完成。
那么我们处理的思路就是增量迭代，即最后的切换阶段耗时最短，我们可以提前复制需要补录的数据，同时对当天的数据进行增量的补录，然后开始切换。
我们可以参考如下的步骤：
1）首先创建同样结构的表，包括索引,一个表是做备份，一个是作为中转。
mysql> create table cmec_log_arch.log like cmec_log.log;
mysql> create table cmec_log_arch.log_new like cmec_log.log;
2）需要把近一个月的数据表现存放到中转表log_new里面，为了提高效率，我们先保证当天的数据有效。
mysql> insert into cmec_log_arch.log_new select * from cmec_log.log where cdate between '2019-09-18' and '2019-09-18 10:00:00'; --当前时间大于10:00:00，但是间隔不大
我们可以缩小时间间隔，完成增量数据的补录，直到增量数据的补录时长控制在秒级（数据集越小，处理时长越短）
2）然后切换表
mysql> RENAME TABLE cmec_log.log TO cmec_log_arch.log_bak,
cmec_log_arch.log TO cmec_log.log,
cmec_log_arch.log_bak TO cmec_log_arch.log;
Query OK, 0 rows affected (0.18 sec)
整个切换过程是很快的。
4）接着我们进行历史数据的补录，完成了当天数据的补录，我们只需要关注历史数据的范围即可。
为了尽可能降低对岸上环境的应县个，我们需要缩小补录的时间范围，比如按照如下的方式来进行补录：insert into cmec_log.log select * from cmec_log_arch.log_new where cdate between '2019-09-16' and '2019-09-17';
因为结果集相对小一些，处理过程对已有的数据处理线程的效率影响最小，可以避免大结果集导致服务阻塞的情况。
当然关键的部分是整个流程梳理完善后固定下来，我们可以把它转换成一个脚本，这样后续的操作我们只需要输入表名，保留的时间范围即可完成这个看起来略微复杂的需求了。
————————————————
版权声明：本文为CSDN博主「jeanron100」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/yangjianrong1985/article/details/102479380