一个20秒SQL慢查询优化的经历与处理方案

背景

前几天在项目上线过程中,发现有一个页面无法正确获取数据,经排查原来是接口调用超时,而最后发现是因为SQL查询长达到20多秒而导致了问题的发生。

这里,没有高深的理论或技术,只是备忘一下经历和解读一些思想误区。

复杂SQL语句的构成

这里不过多对业务功能进行描述,但为了突出问题所在,会用类比的语句来描述当时的场景。复杂的SQL语句可以表达如下:

SELECT * FROM a_table AS a 
LEFT JOIN b_table AS b ON a.id=b.id 
WHERE a.id IN (
    SELECT DISTINCT id FROM a_table 
    WHERE user_id IN (100,102,103) GROUP BY user_id HAVING count(id) > 3
)

关联查询

从上面简化的SQL语句,可以看出,首先进行的是关联查询。

子查询

其次,是嵌套的子查询。此子查询是为了找出多个用户共同拥有的组ID。所以语句中的“100,102,103”是根据场景来定的,并且需要和后面“count(id) > 3”的个数对应。简单来说,就是找用户交集的组ID。

耗时在哪?

假设现在a_table表的数据量为20W,而b_table的数据量为2000W。大家可以想一下,你觉得主要的耗时是在关联查询部分,还是在子查询部分?

(思考空间。。。。)

(思考空间。。。。 。。。)

(思考空间。。。。 。。。 。。。)

问题定位

对于SQL底层的原理和高深的理论,我暂时掌握不够深入。但我知道可以通过类比和简单的测试来验证是哪一块环节出了问题。

初步断定

首先,对于只有一个用户ID时,我会把上面的语句简化成:

SELECT * FROM a_table AS a 
LEFT JOIN b_table AS b ON a.id=b.id 
WHERE user_id IN (100)

所以,初步断定应该是嵌套的子查询部分占用了大部分的时间。

再进一步验证

既然定位到了是嵌套的子查询语句的问题,那又要分为两块待排查的区域:是子查询本身耗时大,还是嵌套而导致慢查询?

结果很容易发现,当我把子查询单独在DB中执行时,是非常快的。所以排除。

剩下的不言而喻,20秒的慢查询是嵌套引起的。

但因为处于上线紧急的过程中,为了确保,我快速地验证了我的结论:

1、将子查询的ID单独执行,并把得到的结果序列手动拼成一段ID,如:1,2,3,4, ... , 999

2、将上面得到的序列ID,手动替换到原来的SQL语句

3、执行,发现,很快!只用了约150 ms

Well Done!  准备修复上线!

解决方案

线上的问题,很多时间都是在定位问题和分析原因,既然问题找到了,原因也找到了,解决方案不言而喻。代码简单处理即可。

另外一个需要注意的点

当前,实际的SQL语句,会比这个更为复杂,但已足以表达问题所在。但在前期,笔者也做了一些SQL的代码。

因为b_table比a_table大,所以一开始 b_table 左关联 a_table 时,很慢,大概是1秒多,而且数据量是很少的;但若反过来,a_table 左关联 b_table 时,则很快,大概是100毫秒。

所以,又发现一个有趣的现象:

大表 左关联 小表,很慢;小表 左关联 右表,很快。

当然,这些我们理论上都知道,但实际开发会忘却。又或者一开始两个表都为空时,而又没考虑到后期这两个表增长的速度时,日后就会埋下坑了。

总结

首先,嵌套的子查询是很慢的。

原因,我还没仔细去研究,但在下班的路上和我的同事交流时,他说曾经看过这方面相关的书籍,是说每一次的子查询都会产生一个SQL语句,所以就N次查询了。而另外一位资深的QA同事则跟我说,应该是M*N的问题。

其次,我一开始使用嵌套子查询,是存在这样一个误区:我觉得将这些操作交给MySQL自身来处理会更高效,毕竟DB内部会有良好的机制来执行这些查询由。

然后,实际表白,我错了。因为这不是简单的合并MC批量查询。

当我们决定使用一些底层的技术时,只有当我们理解透彻了,才能使用更为恰当。而因为无知就断定工具、框架、底层无所不能时,往往就会中招。

时间: 2024-10-29 09:30:19

一个20秒SQL慢查询优化的经历与处理方案的相关文章

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

提示用户输入一个时间的秒数,比如500秒就输入500,然后输出对应的分钟和秒,比如500s就是8分钟20秒

#include <stdio.h> /* */ int main() { /* // 将c的值固定在10以内 int a = 96546546; int c = a % 10; */ // 1.提示用户输入时间 printf("请输入一个时间值(秒):\n"); // 2.接收用户输入的时间 int time; scanf("%d", &time); // 3.转换成对应的分钟和秒 int minute = time / 60; // 分钟 i

棋牌外挂年入千万,20秒小视频骗遍宅男,揭秘诱导欺诈_转

转自:棋牌外挂年入千万,20秒小视频骗遍宅男,揭秘诱导欺诈   https://news.cnblogs.com/n/618203/ 文/木子梨 来源:一本黑(ID:darkinsider) 在如今这个“流量为王”的时代,毫不夸张的说,流量就等同于金钱. 话虽如此,但如何最大限度的把流量换成金钱,这是一门学问. 金钱在诱惑骗子,骗子只能来诱惑你. 那些你也许从来都不屑的软件,实则充满着令人不可思议的套路和暴利. 01 一款棋牌辅助软件中,竟隐藏着年收入近 5000 万的诱导支付交易 最近,在一次

SQL Server查询优化方法参考(转)

今天看到一位博友的文章,觉得不错,转载一下,希望对大家有帮助,更多文章,请访问:http://blog.haoitsoft.com 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用户查看,原因是读写竞

SQL Server查询优化方法(查询速度慢的原因很多,常见如下几种) .

SQL Server查询优化方法(查询速度慢的原因很多,常见如下几种) 标签: sql server优化数据库服务器 2014-12-31 10:13 11988人阅读 评论(0) 收藏 举报 本文章已收录于: 今天看到一位博友的文章,觉得不错,转载一下,希望对大家有帮助,更多文章,请访问:http://blog.haoitsoft.com 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存

一个有趣的SQL Server 层级汇总数据问题

看SQL Server大V宋大侠的博客文章,发现了一个有趣的sql server层级汇总数据问题. 具体的问题如下: parent_id emp_id emp_name total_amout     NULL 2 Andrew 200     2 1 Nancy 100     2 3 Janet 120     3 4 Michael 80     1 5 Robert 50     每个员工的总销售额=自己的销售额+其下级员工的总销售额,     比如:     Andrew = 200_

CocosCreator手记04——是男人就坚持20秒Remastered (TypeScript版)

CocosCreator v1.5.0 tsc Version 2.3.4 密集恐惧症慎用 是男人就坚持20秒属于经典的弹幕游戏,做例子研究也很有价值,足够小且完整,还有相当的游戏性.这是很多Demo所不具备的.这两天用TypeScript语言Remastered了一下,之前那个是C++写的. 感觉上,CocosCreator+TypeScript写起东西来非常顺手.CocosCreator内部提供了很多成熟的快速开发功功能,比起以前效率提高不少.TypeScript的各种提示识别,变量函数增删

SQL点滴10—使用with语句来写一个稍微复杂sql语句,附加和子查询的性能对比

原文:SQL点滴10-使用with语句来写一个稍微复杂sql语句,附加和子查询的性能对比 今天偶尔看到sql中也有with关键字,好歹也写了几年的sql语句,居然第一次接触,无知啊.看了一位博主的文章,自己添加了一些内容,做了简单的总结,这个语句还是第一次见到,学习了.我从简单到复杂地写,希望高手们不要见笑.下面的sql语句设计到三个表,表的内容我用txt文件复制进去,这里不妨使用上一个随笔介绍的建立端到端的package的方法将这些表导入到数据库中,具体的就不说了. 从这里下载文件employ

下一个20年全球开发者将过亿?Tesra超算网络与开发者一起迎接AI时代的到来!

在2018年10月24日的全球开发者节上,?IT 技术社区 CSDN 创始人称下一个 20 年,全球开发者的数量将过亿. AI已经诞生六十年,经历了低谷,也经历了高潮.2016年AlphaGo 取得了重大突破,导致大众媒体对事态的关注增加,而对于人工智能的关注也到了最高峰,AI时代的大门已经打开. 很多人担心AI时代全面来临之后程序员会被取代,实际上这种担心是完全没有必要的.从PC互联网到移动互联网,程序员的增长是数百万级的,而在未来,所有的公司都将会是技术性公司,所有的公司都会数字化,只要数字