一个诡异的MySQL查询超时问题,居然隐藏着存在了两年的BUG
这一周线上碰到一个诡异的BUG。
线上有个定时任务,这个任务需要查询一个表几天范围内的一些数据做一些处理,每隔十分钟执行一次,直至成功。
通过日志发现,从凌晨5:26分开始到5:56任务执行了三次,三次都因为SQL查询超时而执行失败,而诡异的是,任务到凌晨6:00多就执行成功了。
每天都是凌晨五点多失败,凌晨六点执行成功。
点开异常日志一看是这样的:
总结来说就是MySQL查询超时。
像这种稳定复现的BUG,我原以为只需三分钟能定位,没有想到却耗费了我半天的时间。
排查之路
Explain
看到超时SQL,大多数人第一反应就是这个SQL没有走索引,我也不例外,我当时的第一反应就是这条SQL没有走索引。于是,我将日志里面的SQL复制了出来,脱敏处理一下大概是这样的一条SQL:
select * from table_a where status_updated_at >= ? and status_updated_at < ?
SQL里面有两个日期参数,这两个起始日期是某种商品的可交易时间区间,相隔三到五天,我取了17天的时间间隔的保守值,Explain了一下这条SQL。
从图上可以看到这条SQL的执行还是走了索引的。走的是根据status_updated_at字段建立的索引。
执行了一下也只耗时了135毫秒。
根据Explain结果,我当时的推断是:这条SQL肯定走了索引,如果没有走索引,那六点多钟的查询肯定也会超时,因为这个表的数据是千万级别的。
为了验证这一推断,我找DBA帮我导出了一下凌晨5点到早上7点关于这个表的慢SQL,DBA告诉我那个时间段没有关于这个表的慢SQL。
这也进一步验证了我说推断:这条SQL走了索引,只是在五点多的时候因为一些神秘原因导致了超时。
接下来,需要做的就是找出这个神秘的原因。
按照以往的经验,我认为有这几点因素会导致查询超时
- MySQL资源竞争
- 数据库备份
- 网络
MySQL资源竞争
首先,我通过监控系统查看了那段时间MySQL的运行情况,连接数和CPU负载等指标都非常正常。所以,因为MySQL负载导致超时首先就可以被排除。
那会不会是其他业务操作这个表影响的呢?
首先,我们线上数据库事务隔离级别设置的是RR(可重复读),因为MVCC的存在,简单的修改肯定是不会影响查询至超时的。
要想影响唯一的可能性就是别的业务在update这个表数据的时候,更新条件没有走索引,导致行锁升级成表锁,并且,这个操作要刚好在凌晨5点多执行,且持续了半个小时。
这个条件非常苛刻,我检查了相关的代码,问了相关负责人,并没有这种情况,所有的更新都是根据Id主键更新的。关键是,如果更新SQL的更新条件没有走索引,肯定会是一个慢SQL的,那么,我们在慢SQL日志文件里面就能找到它,实际上并没有。
备份
是不是因为凌晨5点多,数据库在备份的原因呢?
首先备份锁表不会锁这么久,这个任务是前前后后半个小时都执行失败了;
其次我们是备份的从库,并不是备份的主库;
最后,我们的备份任务都不是凌晨五点执行的。
所以,因为备份导致超时可以排除了。
网络
是不是网络波动的原因呢?
我找运维同学帮忙看了一下执行任务的那台机器那段时间的网络情况,非常平缓没有丝毫问题,机房也没有出现什么网络抖动的情况。
再者,如果是网络问题,肯定会影响其他任务和业务的,事实上,从监控系统中查看其他业务并没有什么异常。
所以,因为网络波动导致超时也可以排除了。
转机
我先后排除了索引、网络、备份、业务竞争MySQL资源等因素,在脑海里模拟了N种情况,脑补了一条SQL整个执行过程,想不到会有什么其他原因了。
这个事情变得诡异了起来,DBA劝我暂时放弃,建议我把任务执行时间延后,加一些监控日志再观察观察。毕竟,又不是不能用。
放弃是不可能放弃的,我是一个铁头娃,遇到BUG不解决睡不着觉。
理清思路,从头来过,我向DBA要了一份线上五点到六点的慢SQL的文件,自己重新找了一遍,还是没有找到这个表相关的慢SQL。
在我突然要放弃的时候,我突然发现SQL日志记录里面的时区都是标准时区的,而我那个任务执行的时候是北京时间,要知道标准时区和北京时区是差了8个小时的!
好家伙!我都要想到量子力学了,结果发现时区没对上?
会不会是DBA找慢SQL的时候时间找错了啊?
我将这个“重大发现”告诉了DBA,DBA帮我重新跑一份慢SQL,好家伙,出现了我想要那个表的慢SQL。
从日志上面可以看到,查询的日期区间从2020年9月到2021年4月,时间跨度7个月。MySQL成本计算的时候认为区间太大,走索引还不如直接扫描全表,最终没有走索引扫描了1800W条数据。
说好的时间区间最多七天呢?怎么变成了七个月?
赶紧定位代码,定位发现底层在取时间区间时,调了一个RPC接口,这个接口预期返回的时间区间只有几天,结果返回了七个月的时间区间。这段逻辑是18年上线的。
于是联系提供这个RPC接口的相关人员,通过查找验证确定这是底层数据的问题,应该返回几天结果返回了几个月。
最后修复了相关数据,增加了相应的校验和监控,重新发布系统,这个存在了两年的BUG也就得以解决了。
这个故事到这里也就结束了。
再回顾一下,还有几个问题需要回答一下:
不走索引,那为什么六点多执行就没有超时呢?
原因就是六点基本上没有业务在调用MySQL,那个时候的MySQL的资源是非常充足的,加上MySQL的机器也配置非常的高,所以这条SQL硬生生跑成功了。听起来有点离谱,但确实是这样的。
为什么这个BUG在线上这么久了,现在才发现?
这个时间区间底层数据用的不多,目前只发现只有这个超时SQL任务在调用。
原来业务量没有这么大,加上机器配置高,扫描整个表也花不了多久时间。凌晨五六点执行,没有对线上的服务造成影响。
任务失败是很正常的,因为还依赖一些其他数据,其他数据提供的时间不确定,所以任务会一直跑直到成功。
总结
复盘一下整个过程,对于这个查询超时SQL问题的排查,我从索引、网络、备份、业务竞争MySQL资源等方面一一分析,却忽略了最重要的因素——执行的到底是哪一条SQL。
我想当然的认为执行的SQL就是我想象中的那样并对此深信不疑,后面的努力也就成了徒劳。
这本是一个简单的问题,我却把他复杂化了,这是不应该的。
这是一个典型的例子,业务量不大的时候埋下的坑,业务发展迅速的时候就暴露了,万幸的是,没有影响到核心交易系统,如果是核心交易系统的话,可能就会导致一次P0的事故。
虽然这个代码不是我写的,但我从中得到的教训就是对线上环境要有敬畏之心,对依赖数据要有怀疑之心,对问题排查要有客观之心。
线上的环境极其复杂,有着各自版本迁移和业务变更遗留下来的数据,这些情况开发人员是无法全部考虑到的,测试也很难覆盖测试,带着主观的想法去写代码很容易导致BUG,有些BUG在业务量还不大的时候不容易引起重视,但随着业务的发展,这些欠下的债终究要还。
你可以保证你写的逻辑没有问题,但是你不能保证服务上游提供的数据都符合预期。多想一下如果上游数据异常,自己写的服务会不会出问题,多加一些数据校验和报警会省去很多不必要的麻烦。
排查问题的时候,一定要客观,不要带着主观感受。本来就是因为主观而导致的BUG,你还想当然的代入去查找问题,这当然会加大排查问题的难度。
一个诡异的MySQL查询超时问题,居然隐藏着存在了两年的BUG的更多相关文章
- SQL Server 页面查询超时(SOS_SCHEDULER_YIELD等待)
一.问题概述 问题大概是这样的,有一个功能页面经常查询超时,有时候就算能查询出来也要很长的时间,但是有时又会很快.遇到的这种问题在排除掉网络原因之后基本上可以从查询语句上去找原因. 编译查询SQL语句 ...
- 使用 mysql-proxy 监听 mysql 查询
什么是 mysql-proxy? mysql-proxy是mysql官方提供的mysql中间件服务,上游可接入若干个mysql-client,后端可连接若干个mysql-server. 它使用mysq ...
- MySQL查询近一个月的数据
MySQL查询近一个月的数据 近一个月统计SQL select user_id, user_name, createtime from t_user where DATE_SUB(CURDATE(), ...
- mysql 查询当天、本周,本月,上一个月的数据---https://www.cnblogs.com/benefitworld/p/5832897.html
mysql 查询当天.本周,本月,上一个月的数据 今天 select * from 表名 where to_days(时间字段名) = to_days(now()); 昨天 SELECT * FROM ...
- MySQL 查询当天、本周,本月、上一个月的数据
mysql查询当天的所有信息: SELECT * FROM 表名 WHERE year(时间字段名)=year(now()) and month(时间字段名) = month(now()) and d ...
- [转]一个用户SQL慢查询分析,原因及优化
来源:http://blog.rds.aliyun.com/2014/05/23/%E4%B8%80%E4%B8%AA%E7%94%A8%E6%88%B7sql%E6%85%A2%E6%9F%A5%E ...
- MySQL 各种超时参数的含义
MySQL 各种超时参数的含义 今日在查看锁超时的设置时,看到show variables like '%timeout%';语句输出结果中的十几种超时参数时突然想整理一下,不知道大家有没有想过,这么 ...
- 如何使用Heartbeat,组建一个高可用性的mysql集群
转了好多次帖子,其实就是为了使用heartbeat来搭建mysql集群,网上很多都是用make来生成RPM来安装,我也找了很多资料,mysql 自带的cluster用户不满意,只能再次vmware虚拟 ...
- Swoole 实战:MySQL 查询器的实现(协程连接池版)
目录 需求分析 使用示例 模块设计 UML 类图 入口 事务 连接池 连接 查询器的组装 总结 需求分析 本篇我们将通过 Swoole 实现一个自带连接池的 MySQL 查询器: 支持通过链式调用构造 ...
随机推荐
- 【转】ICP算法(Iterative Closest Point迭代最近点算法)
原文网址:https://www.cnblogs.com/sddai/p/6129437.html.转载主要方便随时可以查看,如有版权要求请及时联系. 最近在做点云匹配,需要用c++实现ICP算法,下 ...
- 02.描述统计 (descriptive statistics)
1.数据的可靠性和有效性 2.利用图表对数据进行可视化 2.1分类变量的可视化 2.11无序分类变量 2.12有序分类变量的可视化 2.1数值变量的可视化 数据的分布
- JUnit5学习之六:参数化测试(Parameterized Tests)基础
欢迎访问我的GitHub https://github.com/zq2599/blog_demos 内容:所有原创文章分类汇总及配套源码,涉及Java.Docker.Kubernetes.DevOPS ...
- 基于docker搭建gitlab
一.概述 GitLab是一个利用 Ruby on Rails 开发的开源应用程序,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目. 它拥有与Github类似的功能,能够浏览 ...
- SpringBoot(七):SpringBoot中如何使用过滤器(Filter)?
方式一: 通过注解方式实现: 1.编写一个Servlet3的注解过滤器(和上一章Servlet相似) 贴代码: package com.example.springbootweb.filter; im ...
- MySQL:安装与配置
记录一次 MySQL 在Windows系统的安装配置过程 安装MySQL 0.下载社区版安装包 官网下载地址:https://dev.mysql.com/downloads/installer/ 1. ...
- cat常用参数
cat 命令格式 cat [选项] [文件] -A, --show-all:等价于 -vET. -b --number-nonblank:和 -n 相似,只不过对于空白行不编号. -e:等价于&qu ...
- 剑指 Offer 40. 最小的k个数 + 优先队列 + 堆 + 快速排序
剑指 Offer 40. 最小的k个数 Offer_40 题目描述 解法一:排序后取前k个数 /** * 题目描述:输入整数数组 arr ,找出其中最小的 k 个数.例如,输入4.5.1.6.2.7. ...
- 04----python入门----文件处理
一.大致介绍 我们在计算机上进行的操作,归根结底是对文件的操作,其实质是由操作系统发送请求,将用户或者应用程序对文件读写操作转换成具体的硬盘指令. 众所周知,内存中的数据是无法永久保存的.在计算机硬件 ...
- shell脚本,mysql数据库的备份-2[mysqldump]
# 数据库IPIP=127.0.0.1# 数据库端口PORT=3306# 数据库用户USER=root# 数据库密码PASSWORD=****# 要备份的数据库TARGET_DB=database_n ...