专栏首页杨建荣的学习笔记如何优雅的实现DML批量操作

如何优雅的实现DML批量操作

这是学习笔记的第 2105 篇文章

昨天处理了一个业务同学的数据需求,简单来说就是对一张大表做一下数据清理,数据量在8千万左右,需要保留近一个月的数据,大概是400万左右。

对于数据的删除处理,尤其是大表的处理,可以借助MySQL特有的一种处理策略,可以参考之前的文章:

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';

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

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

个人新书 《MySQL DBA工作笔记》

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes),作者:杨建荣

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-09-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • redo日志文件学习(22天)

    关于redo日志文件,今天因为要做redo日志的在线迁移,所以特意做了个简单的总结。 1. 如果要把redo的切换信息显示到alert日志中,需要设置个参数。...

    jeanron100
  • ​一些不规范的GTID使用场景

    GTID是一种很不错的复制解决方案,但是在使用中还是碰到一些问题,经过整理我梳理了如下的一些不规范的GTID使用场景

    jeanron100
  • MySQL分布式管理初步设计

    中间件方案对于业务的使用相对是透明的,而且扩展性相对较好,这里说较好,是基于良好的架构设计,对于弹性伸缩的支持还是有限的。

    jeanron100
  • 来自mooon的最简单的日志类CSimpleLogger

     * 单个头文件,可即时独立使用,只要定义了宏NOT_WITH_MOOON,即不依赖于mooon

    一见
  • 每个程序员都应该收藏的算法复杂度速查表

    算法复杂度这件事 这篇文章覆盖了计算机科学里面常见算法的时间和空间的大 O(Big-O)复杂度。我之前在参加面试前,经常需要花费很多时间从互联网上查找各种搜索和...

    用户1667431
  • 每个程序员都应该收藏的算法复杂度速查表

    这篇文章覆盖了计算机科学里面常见算法的时间和空间的大 O(Big-O)复杂度。我之前在参加面试前,经常需要花费很多时间从互联网上查找各种搜索和排序算法的优劣,以...

    哲洛不闹
  • 机器学习 - 交叉熵Cross Entropy

    假设训练数据 D={(x1,y1),(x2,y2),...,(xn,yn)}D={(x1,y1),(x2,y2),...,(xn,yn)}D = \{(x_1,...

    AIHGF
  • MySQL配置文件及参数详解

    MySQL的配置文件需要根据版本及实际情况进行相应配置,本人使用的是Percona版本,主要是用到线程池等功能,所以选择Percona版本,配置文件内容如下,大...

    July
  • logstash grok配置规则

    这里主要需要配置grok match,把日志信息切分成索引数据(match本质是一个正则匹配)

    李国宝
  • 生产环境trace log等日志清理脚本

    log_file1日志文件保留40天,log_file2保留45天,即-mtime +xx表示xx天之前。

    loong576

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动