一个 20 秒 SQL 慢查询优化处理方案
1.背景
页面无法正确获取数据，经排查原来是接口调用超时，而最后发现是因为SQL查询长达到20多秒而导致了问题的发生。
这里，没有高深的理论或技术，只是备忘一下经历和解读一些思想误区。
2.复杂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 )
3.关联查询
从上面简化的SQL语句，可以看出，首先进行的是关联查询。
4.子查询
其次，是嵌套的子查询。此子查询是为了找出多个用户共同拥有的组ID。所以语句中的“100,102,103”是根据场景来定的，并且需要和后面“count(id) > 3”的个数对应。简单来说，就是找用户交集的组ID。
5.耗时在哪？
假设现在a_table表的数据量为20W，而b_table的数据量为2000W。大家可以想一下，你觉得主要的耗时是在关联查询部分，还是在子查询部分？
（思考空间。。。。）
（思考空间。。。。。。。）
（思考空间。。。。。。。。。。）
6.问题定位
对于SQL底层的原理和高深的理论，我暂时掌握不够深入。但我知道可以通过类比和简单的测试来验证是哪一块环节出了问题。
7.初步断定
首先，对于只有一个用户ID时，我会把上面的语句简化成：
ELECT * FROM a_table AS a LEFT JOIN b_table AS b ON a.id=b.id WHERE user_id IN (100)
所以，初步断定应该是嵌套的子查询部分占用了大部分的时间。
9.再进一步验证
既然定位到了是嵌套的子查询语句的问题，那又要分为两块待排查的区域：是子查询本身耗时大，还是嵌套而导致慢查询？
结果很容易发现，当我把子查询单独在DB中执行时，是非常快的。所以排除。
剩下的不言而喻，20秒的慢查询是嵌套引起的。
但因为处于上线紧急的过程中，为了确保，我快速地验证了我的结论：
- 1、将子查询的ID单独执行，并把得到的结果序列手动拼成一段ID，如：1,2,3,4, … , 999
- 2、将上面得到的序列ID，手动替换到原来的SQL语句
- 3、执行，发现，很快！只用了约150 ms
Well Done! 准备修复上线！
10.解决方案
线上的问题，很多时间都是在定位问题和分析原因，既然问题找到了，原因也找到了，解决方案不言而喻。代码简单处理即可。
11.另外一个需要注意的点
当前，实际的SQL语句，会比这个更为复杂，但已足以表达问题所在。但在前期，笔者也做了一些SQL的代码。
因为b_table比a_table大，所以一开始b_table 左关联a_table 时，很慢，大概是1秒多，而且数据量是很少的；但若反过来，a_table 左关联b_table 时，则很快，大概是100毫秒。
所以，又发现一个有趣的现象：
大表 左关联 小表，很慢；小表 左关联 大表，很快。
当然，这些我们理论上都知道，但实际开发会忘却。又或者一开始两个表都为空时，而又没考虑到后期这两个表增长的速度时，日后就会埋下坑了。
总结：
首先，嵌套的子查询是很慢的。
原因，我还没仔细去研究，但在下班的路上和我的同事交流时，他说曾经看过这方面相关的书籍，是说每一次的子查询都会产生一个SQL语句，所以就N次查询了。而另外一位资深的QA同事则跟我说，应该是M*N的问题。
其次，我一开始使用嵌套子查询，是存在这样一个误区：我觉得将这些操作交给MySQL自身来处理会更高效，毕竟DB内部会有良好的机制来执行这些查询由。
然后，实际表白，我错了。因为这不是简单的合并MC批量查询。
当我们决定使用一些底层的技术时，只有当我们理解透彻了，才能使用更为恰当。而因为无知就断定工具、框架、底层无所不能时，往往就会中招。
到此这篇关于一个 20 秒 SQL 慢查询优化的经历与处理方案的文章就介绍到这了,更多相关 SQL 慢查询优化的经历与处理方案内容请搜索猪先飞以前的文章或继续浏览下面的相关文章希望大家以后多多支持猪先飞！
原文出处：https://my.oschina.net/dogstar/blog/398879
相关文章
- 本文给大家分享C#连接SQL数据库和查询数据功能的操作技巧，本文通过图文并茂的形式给大家介绍的非常详细，需要的朋友参考下吧...2021-05-17
- 这篇文章主要介绍了MySQL性能监控软件Nagios的安装及配置教程,这里以CentOS操作系统为环境进行演示,需要的朋友可以参考下...2015-12-14
- 这篇文章主要介绍了PostgreSQL判断字符串是否包含目标字符串的多种方法,本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下...2021-02-23
- 这篇文章主要介绍了PostgreSQL TIMESTAMP类型 时间戳操作，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧...2020-12-26
- 新版 Mysql 中加入了对 JSON Document 的支持，可以创建 JSON 类型的字段，并有一套函数支持对JSON的查询、修改等操作，下面就实际体验一下...2016-08-23
- 这篇文章主要介绍了postgresql 实现多表关联删除操作，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧...2021-01-02
- 这篇文章主要介绍了Postgresl 如何选择正确的关闭模式，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧...2021-01-18
深入研究mysql中的varchar和limit(容易被忽略的知识)
为什么标题要起这个名字呢？commen sence指的是那些大家都应该知道的事情，但往往大家又会会略这些东西，或者对这些东西一知半解，今天我总结下自己在mysql中遇到的一些commen sense类型的问题。 ...2015-03-15- 这篇文章主要介绍了postgresql数据添加两个字段联合唯一的操作，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧...2021-02-04
- 这篇文章主要介绍了MySQL 字符串拆分操作(含分隔符的字符串截取)，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧...2021-02-22
- 关于mysql效率优化一般通过以下两种方式定位执行效率较低的sql语句。通过慢查询日志定位那些执行效率较低的 SQL 语句，用 --log-slow-queries[=file_name] 选项启动时， mysqld 会 写一个包含所有执行时间超过 long_quer...2015-11-08
- 一、先说一下为什么要分表：当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。根据个人经验，mysql执行一个sql的过程如下：1...2014-05-31
- java开发的Android应用，性能一直是一个大问题，，或许是Java语言本身比较消耗内存。本文我们来谈谈Android 性能优化之MemoryFile文件读写。 Android匿名共享内存对外A...2016-09-20
- 过了这么久，discuz论坛的问题还是困扰着很多网友，其实从各论坛里看到的问题总结出来，很关键的一点都是因为没有将数据表引擎转成InnoDB导致的，discuz在并发稍微高一点的环境下就表现的非常糟糕，产生大量的锁等待，这时候如果...2015-11-24
- 这篇文章主要介绍了Vscode上使用SQL的方法,本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下...2021-01-26
- 我们自己鼓捣mysql时，总免不了会遇到这个问题：插入中文字符出现乱码，虽然这是运维先给配好的环境，但是在自己机子上玩的时候咧，总得知道个一二吧，不然以后如何优雅的吹牛B。...2015-03-15
- MySQL是一个功能强大的开源数据库。随着越来越多的数据库驱动的应用程序，人们一直在推动MySQL发展到它的极限。这里是101条调节和优化 MySQL安装的技巧。一些技巧是针对特定的安装环境的，但这些思路是通用的。我已经把...2013-09-11
- 这篇文章主要介绍了PostgreSQL 字符串处理与日期处理操作，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧...2021-02-01
- 这几天在centos下装mysql，这里记录一下安装的过程，方便以后查阅Mysql5.5.37安装需要cmake，5.6版本开始都需要cmake来编译，5.5以后的版本应该也要装这个。安装cmake复制代码 代码如下: [root@local ~]# wget http://www.cm...2015-03-15
- 这篇文章主要介绍了postgresql重置序列起始值，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧...2021-01-04