关于Mysql使用left join写查询语句执行很慢的问题解决

Posted zyypjc

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于Mysql使用left join写查询语句执行很慢的问题解决相关的知识,希望对你有一定的参考价值。

目录

(一)前言

(二)正文

1. 表结构/索引展示

(1)表结构

(2)各表索引情况

2. 存在性能问题的SQL语句

3. 解决思路

(1)执行计划思路调优

(2)字符集匹配调优

(三)总结

1. 关于执行计划中TYPE的性能比较

2. 关于left join优化

3. 其他注意点


(一)前言

这几天供应商在测试环境上使用mysql数据库做开发时遇到一个SQL性能问题,即在他开发环境本地跑SQL速度很快就一两秒时间,但是同样的SQL放在测试环境上死活跑了很久一直出不了结果。最后求助到我这边,以下正文是我解决这次问题的一个过程浅谈,供大家参考。

(二)正文

本文使用NAVICAT试用版作为基础工具来说明,需要永久激活的可以在网上找到相关介绍走正式途径。

其次附上一篇文章,解释说明如果在NAVICAT中运行一条长时间的SQL想关闭终止它,图形化点击失败时候所应该采取的方式,文章链接如下:

在Navicat上如何停止正在运行的MYSQL语句_zyypjc的博客-CSDN博客

1. 表结构/索引展示

以下将大致描述下本次遇到性能问题涉及的两张表(rep_consultant_first和rep_newcomer_consultant)的表结构和索引。

(1)表结构

a. rep_consultant_first

b. rep_newcomer_consultant

 

(2)各表索引情况

 a. rep_consultant_first

b. rep_newcomer_consultant

2. 存在性能问题的SQL语句

这条SQL语句的意图在于找出rep_newcomer_consultant表中缺失的存在于rep_consultant_first表中的数据,即可求这两张表的差集(rep_consultant_first - rep_newcomer_consultant),简单说就是下图里的红色填充区域。

select consultantNumber,
       customerId,userName,
			 telephoneNumber,
			 sponsorConsultantNumber,
			 signUpDate 
from rep_consultant_first rcf left join rep_newcomer_consultant rnco
 on rnco.rncoConsultantNumber=rcf.consultantNumber
where rnco.rncoConsultantNumber is null;

 直接运行后我们发现这条语句运行了好几十分钟依旧没有结果,假如只是稍微慢一点那可能勉强说得过去,但是目前这种情况实在是到无法接受的情况了!!!

3. 解决思路

(1)执行计划思路调优

一般SQL慢了,第一个想的一定是查一下执行计划是不是哪个环节没有走索引,走了全表扫描,让我们选中SQL部分,点击“解释已选择的”来看下这条SQL的执行计划详情:

 从执行计划中我们看到别名为rcf(即rep_consultant_first表)的type方式走了ALL,即全表扫描,那自然而然我们会先想从这里去优化。

回到rep_consultant_first表的索引位置,我们看到在select后筛出来的字段里只有consultant number和sponsorConsultantNumber字段上有索引而其他并没有,所以不可避免走了全表扫描

那我们先尝试下给未加索引的字段加上一组索引,大致流程如下:

a. 找到所要加索引字段所在的表(rep_consultant_first),右键点击后选择"设计表"

b. 找到索引选项卡,添加索引TestIndex,最后点击保存。

 

 

让我们重新回到一开始的SQL,看一下加完索引后是否执行计划有优化:

可以看出,执行计划的TYPE从ALL变成了INDEX且EXTRA列明确说明了Using index了,那说明执行计划确实改变了,没有扫全表,不过遗憾的是。。。SQL依旧跑不出来。。。

(2)字符集匹配调优

此时真的黔驴技穷了么??还真没有 !足球篮球世界里我们经常看到最后时刻逆袭的致命一击取得胜利,在SQL优化里我们同样有这样的机会! 仔细回想了下,似乎在MYSQL相关手册资料中的优化TIPS里除了添加相关字段索引之外,那left join中关联两表的字段,字符集是否需要统一???

有了这个思路,我们立马着手再看下这条问题SQL语句,我们重点关注rep_consultant_first表上的consultantNumber字段以及rep_newcomer_consultant表上的rncoConsultantNumber字段:

对比之下,立马看出了区别!在rep_consultant_first上字段consultantNumber的字符集为utf8mb4,而rep_newcomer_consultant上字段rncoConsultantNumber的字符集为gbk。在官方相关文档中提到过关联字段除了需要有索引外,拥有相同的字符集以及数据类型相当重用,这会极大影响查询速度!

接下来我们来具体操作下,可以将rep_newcomer_consultant上字段rncoConsultantNumber的字符集改从gbk改为utf8mb4,排序方式也改为和rep_consultant_first表一样的utf8mb4_0900_ai_ci试一试,点击保存按钮:

保存成功后,我们立马再运行下慢SQL:

一下子只有0.885秒了!!速度飙升到无法言喻的速度!至此我们基本算优化成功了。

(三)总结

经过这个案例后,我搜罗总结了下本例涉及到一些优化注意点:

1. 关于执行计划中TYPE的性能比较

 

2. 关于left join优化

1、left join选择小表作为驱动表(这部分基本是大家的共识)

2、如果左表比较大,并且业务要求驱动表必须是左表,那么我们可以通过where条件语句,使得左表被过滤的小一些,主要原理和第一条类似

3、关联字段给索引,因为在mysql的嵌套循环算法中,是通过关联字段进行关联,并查询的,所以给关联字段索引很必要

4、如果sql里面有排序,请给排序字段加上索引,不然会造成排序使用全表扫描
        参考:https://www.oschina.net/question/930697_2190172      
5、如果where条件中含有右表的非空条件(除开is null),则left join语句等同于join语句,可直接改写成join语句。 

6、根据文档,MySQL能更高效地在声明具有相同类型和尺寸的列上使用索引。所以把表与表之间的关联字段给上encoding和collation(决定字符比较的规则)全部改成统一的类型

7、右表的条件列一定要加上索引(主键、唯一索引、前缀索引等),最好能够使type达到range及以上(ref,eq_ref,const,system) 

3. 其他注意点

mysql查询语句的执行顺序(重点)

一 SELECT语句关键字的定义顺序

SELECT DISTINCT <select_list>
FROM <left_table>
<join_type> JOIN <right_table>
ON <join_condition>
WHERE <where_condition>
GROUP BY <group_by_list>
HAVING <having_condition>
ORDER BY <order_by_condition>
LIMIT <limit_number>

二 SELECT语句关键字的执行顺序

(7)     SELECT 
(8)     DISTINCT <select_list>
(1)     FROM <left_table>
(3)     <join_type> JOIN <right_table>
(2)     ON <join_condition>
(4)     WHERE <where_condition>
(5)     GROUP BY <group_by_list>
(6)     HAVING <having_condition>
(9)     ORDER BY <order_by_condition>
(10)    LIMIT <limit_number>

三 准备表和数据

1. 新建一个测试数据库TestDB;

create database TestDB;

2.创建测试表table1和table2;

CREATE TABLE table1
 (
     customer_id VARCHAR(10) NOT NULL,
     city VARCHAR(10) NOT NULL,
     PRIMARY KEY(customer_id)
 )ENGINE=INNODB DEFAULT CHARSET=UTF8;

 CREATE TABLE table2
 (
     order_id INT NOT NULL auto_increment,
     customer_id VARCHAR(10),
     PRIMARY KEY(order_id)
 )ENGINE=INNODB DEFAULT CHARSET=UTF8;

3.插入测试数据;

 INSERT INTO table1(customer_id,city) VALUES(163,hangzhou);
 INSERT INTO table1(customer_id,city) VALUES(9you,shanghai);
 INSERT INTO table1(customer_id,city) VALUES(tx,hangzhou);
 INSERT INTO table1(customer_id,city) VALUES(baidu,hangzhou);

 INSERT INTO table2(customer_id) VALUES(163);
 INSERT INTO table2(customer_id) VALUES(163);
 INSERT INTO table2(customer_id) VALUES(9you);
 INSERT INTO table2(customer_id) VALUES(9you);
 INSERT INTO table2(customer_id) VALUES(9you);
 INSERT INTO table2(customer_id) VALUES(tx);
 INSERT INTO table2(customer_id) VALUES(NULL);

准备工作做完以后,table1和table2看起来应该像下面这样:

mysql> select * from table1;
 +-------------+----------+
 | customer_id | city     |
 +-------------+----------+
 | 163         | hangzhou |
 | 9you        | shanghai |
 | baidu       | hangzhou |
 | tx          | hangzhou |
 +-------------+----------+
 4 rows in set (0.00 sec)

 mysql> select * from table2;
 +----------+-------------+
 | order_id | customer_id |
 +----------+-------------+
 |        1 | 163         |
 |        2 | 163         |
 |        3 | 9you        |
 |        4 | 9you        |
 |        5 | 9you        |
 |        6 | tx          |
 |        7 | NULL        |
 +----------+-------------+
 7 rows in set (0.00 sec)

四 准备SQL逻辑查询测试语句

#查询来自杭州,并且订单数少于2的客户。
 SELECT a.customer_id, COUNT(b.order_id) as total_orders
 FROM table1 AS a
 LEFT JOIN table2 AS b
 ON a.customer_id = b.customer_id
 WHERE a.city = hangzhou
 GROUP BY a.customer_id
 HAVING count(b.order_id) < 2
 ORDER BY total_orders DESC;

五 执行顺序分析

在这些SQL语句的执行过程中,都会产生一个虚拟表,用来保存SQL语句的执行结果(这是重点),我现在就来跟踪这个虚拟表的变化,得到最终的查询结果的过程,来分析整个SQL逻辑查询的执行顺序和过程。

执行FROM语句

第一步,执行FROM语句。我们首先需要知道最开始从哪个表开始的,这就是FROM告诉我们的。现在有了<left_table><right_table>两个表,我们到底从哪个表开始,还是从两个表进行某种联系以后再开始呢?它们之间如何产生联系呢?——笛卡尔积

关于什么是笛卡尔积,请自行Google补脑。经过FROM语句对两个表执行笛卡尔积,会得到一个虚拟表,暂且叫VT1(vitual table 1),内容如下:

+-------------+----------+----------+-------------+
| customer_id | city     | order_id | customer_id |
+-------------+----------+----------+-------------+
| 163         | hangzhou |        1 | 163         |
| 9you        | shanghai |        1 | 163         |
| baidu       | hangzhou |        1 | 163         |
| tx          | hangzhou |        1 | 163         |
| 163         | hangzhou |        2 | 163         |
| 9you        | shanghai |        2 | 163         |
| baidu       | hangzhou |        2 | 163         |
| tx          | hangzhou |        2 | 163         |
| 163         | hangzhou |        3 | 9you        |
| 9you        | shanghai |        3 | 9you        |
| baidu       | hangzhou |        3 | 9you        |
| tx          | hangzhou |        3 | 9you        |
| 163         | hangzhou |        4 | 9you        |
| 9you        | shanghai |        4 | 9you        |
| baidu       | hangzhou |        4 | 9you        |
| tx          | hangzhou |        4 | 9you        |
| 163         | hangzhou |        5 | 9you        |
| 9you        | shanghai |        5 | 9you        |
| baidu       | hangzhou |        5 | 9you        |
| tx          | hangzhou |        5 | 9you        |
| 163         | hangzhou |        6 | tx          |
| 9you        | shanghai |        6 | tx          |
| baidu       | hangzhou |        6 | tx          |
| tx          | hangzhou |        6 | tx          |
| 163         | hangzhou |        7 | NULL        |
| 9you        | shanghai |        7 | NULL        |
| baidu       | hangzhou |        7 | NULL        |
| tx          | hangzhou |        7 | NULL        |
+-------------+----------+----------+-------------+

总共有28(table1的记录条数 * table2的记录条数)条记录。这就是VT1的结果,接下来的操作就在VT1的基础上进行。

执行ON过滤

执行完笛卡尔积以后,接着就进行ON a.customer_id = b.customer_id条件过滤,根据ON中指定的条件,去掉那些不符合条件的数据,得到VT2表,内容如下:

+-------------+----------+----------+-------------+
| customer_id | city     | order_id | customer_id |
+-------------+----------+----------+-------------+
| 163         | hangzhou |        1 | 163         |
| 163         | hangzhou |        2 | 163         |
| 9you        | shanghai |        3 | 9you        |
| 9you        | shanghai |        4 | 9you        |
| 9you        | shanghai |        5 | 9you        |
| tx          | hangzhou |        6 | tx          |
+-------------+----------+----------+-------------+

VT2就是经过ON条件筛选以后得到的有用数据,而接下来的操作将在VT2的基础上继续进行。

添加外部行

这一步只有在连接类型为OUTER JOIN时才发生,如LEFT OUTER JOINRIGHT OUTER JOINFULL OUTER JOIN。在大多数的时候,我们都是会省略掉OUTER关键字的,但OUTER表示的就是外部行的概念。

LEFT OUTER JOIN把左表记为保留表,得到的结果为:

+-------------+----------+----------+-------------+
| customer_id | city     | order_id | customer_id |
+-------------+----------+----------+-------------+
| 163         | hangzhou |        1 | 163         |
| 163         | hangzhou |        2 | 163         |
| 9you        | shanghai |        3 | 9you        |
| 9you        | shanghai |        4 | 9you        |
| 9you        | shanghai |        5 | 9you        |
| tx          | hangzhou |        6 | tx          |
| baidu       | hangzhou |     NULL | NULL        |
+-------------+----------+----------+-------------+

RIGHT OUTER JOIN把右表记为保留表,得到的结果为:

+-------------+----------+----------+-------------+
| customer_id | city     | order_id | customer_id |
+-------------+----------+----------+-------------+
| 163         | hangzhou |        1 | 163         |
| 163         | hangzhou |        2 | 163         |
| 9you        | shanghai |        3 | 9you        |
| 9you        | shanghai |        4 | 9you        |
| 9you        | shanghai |        5 | 9you        |
| tx          | hangzhou |        6 | tx          |
| NULL        | NULL     |        7 | NULL        |
+-------------+----------+----------+-------------+

FULL OUTER JOIN把左右表都作为保留表,得到的结果为:

+-------------+----------+----------+-------------+
| customer_id | city     | order_id | customer_id |
+-------------+----------+----------+-------------+
| 163         | hangzhou |        1 | 163         |
| 163         | hangzhou |        2 | 163         |
| 9you        | shanghai |        3 | 9you        |
| 9you        | shanghai |        4 | 9you        |
| 9you        | shanghai |        5 | 9you        |
| tx          | hangzhou |        6 | tx          |
| baidu       | hangzhou |     NULL | NULL        |
| NULL        | NULL     |        7 | NULL        |
+-------------+----------+----------+-------------+

添加外部行的工作就是在VT2表的基础上添加保留表中被过滤条件过滤掉的数据,非保留表中的数据被赋予NULL值,最后生成虚拟表VT3。

由于我在准备的测试SQL查询逻辑语句中使用的是LEFT JOIN,过滤掉了以下这条数据:

| baidu       | hangzhou |     NULL | NULL        |

现在就把这条数据添加到VT2表中,得到的VT3表如下:

+-------------+----------+----------+-------------+
| customer_id | city     | order_id | customer_id |
+-------------+----------+----------+-------------+
| 163         | hangzhou |        1 | 163         |
| 163         | hangzhou |        2 | 163         |
| 9you        | shanghai |        3 | 9you        |
| 9you        | shanghai |        4 | 9you        |
| 9you        | shanghai |        5 | 9you        |
| tx          | hangzhou |        6 | tx          |
| baidu       | hangzhou |     NULL | NULL        |
+-------------+----------+----------+-------------+

接下来的操作都会在该VT3表上进行。

执行WHERE过滤

对添加外部行得到的VT3进行WHERE过滤,只有符合<where_condition>的记录才会输出到虚拟表VT4中。当我们执行WHERE a.city = ‘hangzhou‘的时候,就会得到以下内容,并存在虚拟表VT4中:

+-------------+----------+----------+-------------+
| customer_id | city     | order_id | customer_id |
+-------------+----------+----------+-------------+
| 163         | hangzhou |        1 | 163         |
| 163         | hangzhou |        2 | 163         |
| tx          | hangzhou |        6 | tx          |
| baidu       | hangzhou |     NULL | NULL        |
+-------------+----------+----------+-------------+

但是在使用WHERE子句时,需要注意以下两点:

  1. 由于数据还没有分组,因此现在还不能在WHERE过滤器中使用where_condition=MIN(col)这类对分组统计的过滤;
  2. 由于还没有进行列的选取操作,因此在SELECT中使用列的别名也是不被允许的,如:SELECT city as c FROM t WHERE c=‘shanghai‘;是不允许出现的。

执行GROUP BY分组

GROU BY子句主要是对使用WHERE子句得到的虚拟表进行分组操作。我们执行测试语句中的GROUP BY a.customer_id,就会得到以下内容(默认只显示组内第一条):

+-------------+----------+----------+-------------+
| customer_id | city     | order_id | customer_id |
+-------------+----------+----------+-------------+
| 163         | hangzhou |        1 | 163         |
| baidu       | hangzhou |     NULL | NULL        |
| tx          | hangzhou |        6 | tx          |
+-------------+----------+----------+-------------+

得到的内容会存入虚拟表VT5中,此时,我们就得到了一个VT5虚拟表,接下来的操作都会在该表上完成。

执行HAVING过滤

HAVING子句主要和GROUP BY子句配合使用,对分组得到的VT5虚拟表进行条件过滤。当我执行测试语句中的HAVING count(b.order_id) < 2时,将得到以下内容:

+-------------+----------+----------+-------------+
| customer_id | city     | order_id | customer_id |
+-------------+----------+----------+-------------+
| baidu       | hangzhou |     NULL | NULL        |
| tx          | hangzhou |        6 | tx          |
+-------------+----------+----------+-------------+

这就是虚拟表VT6。

SELECT列表

现在才会执行到SELECT子句,不要以为SELECT子句被写在第一行,就是第一个被执行的。

我们执行测试语句中的SELECT a.customer_id, COUNT(b.order_id) as total_orders,从虚拟表VT6中选择出我们需要的内容。我们将得到以下内容:

+-------------+--------------+
| customer_id | total_orders |
+-------------+--------------+
| baidu       |            0 |
| tx          |            1 |
+-------------+--------------+

还没有完,这只是虚拟表VT7。

执行DISTINCT子句

如果在查询中指定了DISTINCT子句,则会创建一张内存临时表(如果内存放不下,就需要存放在硬盘了)。这张临时表的表结构和上一步产生的虚拟表VT7是一样的,不同的是对进行DISTINCT操作的列增加了一个唯一索引,以此来除重复数据。

由于我的测试SQL语句中并没有使用DISTINCT,所以,在该查询中,这一步不会生成一个虚拟表。

执行ORDER BY子句

对虚拟表中的内容按照指定的列进行排序,然后返回一个新的虚拟表,我们执行测试SQL语句中的ORDER BY total_orders DESC,就会得到以下内容:

+-------------+--------------+
| customer_id | total_orders |
+-------------+--------------+
| tx          |            1 |
| baidu       |            0 |
+-------------+--------------+

可以看到这是对total_orders列进行降序排列的。上述结果会存储在VT8中。

执行LIMIT子句

LIMIT子句从上一步得到的VT8虚拟表中选出从指定位置开始的指定行数据。对于没有应用ORDER BY的LIMIT子句,得到的结果同样是无序的,所以,很多时候,我们都会看到LIMIT子句会和ORDER BY子句一起使用。

MySQL数据库的LIMIT支持如下形式的选择:

LIMIT n, m

表示从第n条记录开始选择m条记录。而很多开发人员喜欢使用该语句来解决分页问题。对于小数据,使用LIMIT子句没有任何问题,当数据量非常大的时候,使用LIMIT n, m是非常低效的。因为LIMIT的机制是每次都是从头开始扫描,如果需要从第60万行开始,读取3条数据,就需要先扫描定位到60万行,然后再进行读取,而扫描的过程是一个非常低效的过程。所以,对于大数据处理时,是非常有必要在应用层建立一定的缓存机制(现在的大数据处理,大都使用缓存)

 

以上是关于关于Mysql使用left join写查询语句执行很慢的问题解决的主要内容,如果未能解决你的问题,请参考以下文章

关于SQL 查询效率问题 left join 改成 inner join union

MySQL Left Join(左连接) 耗时严重的问题

mysql-语句查询执行顺序

MySQL的逻辑查询语句的执行顺序

mysql查询语句的执行顺序(重点)

mysql第四篇--SQL逻辑查询语句执行顺序