慢 SQL 打爆监控!亿级数据表的删除问题

背景

简单抽象下业务场景,有一张 MySQL 表用来存储用户的操作日志,需要依赖这个日志来做一些业务逻辑的判断,并且每个用户可以存在多条日志,所以可想而知,随着时间的推移,这张表肯定是会越来越大的,必须要做治理。

秉持着最简原则,我们暂时不考虑分库分表,数据能删则删,因为表中数据其实并不是每一条都有用,梳理了下业务之后,我们最终的治理方向就是:

  1. Job 每个月定时执行一次来删除数据

  2. 保留近 3 个月的数据,之前的数据可以删除

  3. 删除并不是无脑删除,每条日志有一个对应的类型 type(取值固定,假设是 a、b、c、d、e 吧),当 type = c 的时候该条日志不能删除(忽略这个奇怪的逻辑,纯属业务需求)

我们可以抽象出这样一张表就命名为 log 吧,它有如下字段:

  • id(主键)

  • type(无索引)

  • datachange_lasttime(时间,有索引)

type 没有索引并且也不适合做索引

删除数据的条件:

  1. datachange_lasttime <= 当前时间 - 3 个月

  2. type != c

以上就是背景,应该比较清楚了

早期方案

首先大表删除的基本方针一定是批量删除,即分批查,分批删。

最基本的方案就是把 datachange_lasttime 和 type 的要求都放在 SQL 中,直接通过 SQL 找到我们要删的数据:

selectidfromlog
where
    datachange_lasttime <= '2023-06-17 00:00:00'
    andtype != 'c'
limit#{limit}

查一次就根据 id 批量删除一次,每次查 limit 条,停止条件就是查不出来数据了

失败的优化方案

早期方案在数据量级几千万的时候还是没问题的,因为我们这个删除只需要离线运行,所以用定时 job 跑就可以,对业务基本没啥影响。

但随着表越来越大,上亿之后,这条 SQL 直接卡住,慢查询告警猛增,已经没有办法正常完成删除了。

type 由于没有索引放在 SQL 中是巨大瓶颈,必须得去掉!datachange_lasttime 也可以从 SQL 中拿出来,查出来之后在内存中再做 type 和 datachange_lasttime 的筛选(也就是在 Java 代码中写这个逻辑),然后再根据 id 批量删除。

查询 SQL 如下:

selectidfromlog
from t_user_pop_log
orderbyid
limit#{offset}, #{limit}

分页查询图方便我直接用的 MyBatis PageHelper,但是很快我就为此付出代价,就是总是有脏数据没删干净,我们举个例子分析下:

  1. 假设表中总数据 300 条

  2. 第一次查询:select * from log limit 0,100; 查出了 100 条数据,但是经过我们 type != c 的过滤后,最终只删除了 50 条数据,那么表中还剩余 250 条数据

  3. 第二次查询,表中有 250 条数据,select * from log limit 101,200; 查出了 100 条数据,但是经过我们 type != c 的过滤后,最终只删除了 60 条数据,那么表中还剩余 190 条数据

  4. 第三次查询,表中有 190 条数据,select * from log limit 201,300; 这次查询就出问题了,因为表中只有 190 条数据了,offset = 201 是查不出来数据的,所以这就导致总有一部分数据是没有经过处理的

想到的解决方案是一直查第一页(也就是 offset = 0),直到第一页没数据,那就停止查询

但是很明显这个停止查询的条件存在问题,如果恰好这一页的所有数据全都是 “type=c”,也就是这一页的数据都是不能删的数据,那么循环就会卡在这一页,因为这一页的数据永远不会发生变化

成功的优化方案

我们看失败方案,其实可以发现失败的最根本原因是 MyBatis Pagehelper 的 offset 的计算不对,考虑我们自己做分页,不用 MyBatis Pagehelper,这样就改成如下方式来分批查询:

select *
from t_user_pop_log
whereid >= #{startId}
orderbyid
limit#{limit}

这条 SQL 中只涉及主键 id,速度是非常快的:

  1. startId 从 1 开始,一次查询 limit 条,根据 id 升序查

  2. 对查询出来的记录做 type != c & datachange_lasttime <= 当前时间 - 3 个月的筛选,从而筛选出需要删除的 id

  3. 根据筛选出来的 id 进行批量删除

  4. 更新下一次查询的 startId = 本次查询结果中最大的 id + 1

  5. 停止条件:如果本次查询结果的第一条记录的 datachange_lasttime > 当前时间 - 3 个月,后面的数据就不需要删除了

上述方案很容易想到一个点,那就是 startId 可以不需要每次都从 1 开始。

每个月删除一次,那其实除了第一次,后续的删除只需要删除一个月的数据,只有第一次删除是需要扫描三个月前的所有数据。举个例子:

  1. 5.1 执行第一次删除,保留近三个月即 2.1 之后的数据,2.1 之前的数据要全部扫描并删除

  2. 6.1 执行第二次删除,保留近三个月即 3.1 之后的数据,2.1 之前的数据已经被删除了,所以这次删除其实只需要删除 从 2.1 开始到 3.1 这一个月的数据就可以了

那么 startId 的初始取值逻辑就是:

  1. 首次删除:startId = 1

  2. 非首次删除:startId = datachange_lastime >=【当前时间 - 3 个月 - 1 个月】的最小 id(还可以给这个时间加一点容错空间,多扫描几天的数据也无妨,比如 15 天,startId = datachange_lastime >=【当前时间 - 3 个月 - 1 个月 - 15 天】的最小 id)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值