MySQL在关联复杂情况下所能做出的一些优化

更新时间：2015年05月08日 09:20:01 作者：罗龙九

这篇文章主要介绍了MySQL在关联复杂情况下所能做出的一些优化,作者通过添加索引来不断优化查询时间,需要的朋友可以参考下

昨天处理了一则复杂关联SQL的优化，这类SQL的优化往往考虑以下四点：

第一.查询所返回的结果集，通常查询返回的结果集很少，是有信心进行优化的；

第二.驱动表的选择至关重要，通过查看执行计划，可以看到优化器选择的驱动表,从执行计划中的rows可以大致反映出问题的所在；

第三.理清各表之间的关联关系，注意关联字段上是否有合适的索引；

第四.使用straight_join关键词来强制表之间的关联顺序，可以方便我们验证某些猜想；

SQL:
执行时间：

mysql> select c.yh_id,
-> c.yh_dm,
-> c.yh_mc,
-> c.mm,
-> c.yh_lx,
-> a.jg_id,
-> a.jg_dm,
-> a.jg_mc,
-> a.jgxz_dm,
-> d.js_dm yh_js
-> from a, b, c
-> left join d on d.yh_id = c.yh_id
-> where a.jg_id = b.jg_id
-> and b.yh_id = c.yh_id
-> and a.yx_bj = ‘Y'
-> and c.sc_bj = ‘N'
-> and c.yx_bj = ‘Y'
-> and c.sc_bj = ‘N'
-> and c.yh_dm = '006939748XX' ;

1 row in set (0.75 sec)

这条SQL查询实际只返回了一行数据，但却执行耗费了750ms，查看执行计划：

mysql> explain
-> select c.yh_id,
-> c.yh_dm,
-> c.yh_mc,
-> c.mm,
-> c.yh_lx,
-> a.jg_id,
-> a.jg_dm,
-> a.jg_mc,
-> a.jgxz_dm,
-> d.js_dm yh_js
-> from a, b, c
-> left join d on d.yh_id = c.yh_id
-> where a.jg_id = b.jg_id
-> and b.yh_id = c.yh_id
-> and a.yx_bj = ‘Y'
-> and c.sc_bj = ‘N'
-> and c.yx_bj = ‘Y'
-> and c.sc_bj = ‘N'
-> and c.yh_dm = '006939748XX' ;

+—-+————-+——-+——–+——————+———+———+————–+——-+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——–+——————+———+———+————–+——-+————-+
| 1 | SIMPLE | a | ALL | PRIMARY,INDEX_JG | NULL | NULL | NULL | 52616 | Using where |
| 1 | SIMPLE | b | ref | PRIMARY | PRIMARY | 98 | test.a.JG_ID | 1 | Using index |
| 1 | SIMPLE | c | eq_ref | PRIMARY | PRIMARY | 98 | test.b.YH_ID | 1 | Using where |
| 1 | SIMPLE | d | index | NULL | PRIMARY | 196 | NULL | 54584 | Using index |
+—-+————-+——-+——–+——————+———+———+————–+——-+————-+

可以看到执行计划中有两处比较显眼的性能瓶颈：

| 1 | SIMPLE | a | ALL | PRIMARY,INDEX_JG | NULL | NULL | NULL | 52616 | Using where |

| 1 | SIMPLE | d | index | NULL | PRIMARY | 196 | NULL | 54584 | Using index |

由于d是left join的表，所以驱动表不会选择d表，我们在来看看a,b,c三表的大小：

mysql> select count(*) from c;
+———-+
| count(*) |
+———-+
| 53731 |
+———-+

mysql> select count(*) from a;
+———-+
| count(*) |
+———-+
| 53335 |
+———-+

mysql> select count(*) from b;
+———-+
| count(*) |
+———-+
| 105809 |
+———-+

由于b表的数据量大于其他的两表，同时b表上基本没有查询过滤条件，所以驱动表选择B的可能排除；

优化器实际选择了a表作为驱动表，而为什么不是c表作为驱动表？我们来分析一下：

第一阶段：a表作为驱动表
a–>b–>c–>d:
(1):a.jg_id=b.jg_id—>(b索引:PRIMARY KEY (`JG_ID`,`YH_ID`) )

(2):b.yh_id=c.yh_id—>(c索引:PRIMARY KEY (`YH_ID`))

(3):c.yh_id=d.yh_id—>(d索引:PRIMARY KEY (`JS_DM`,`YH_ID`))
由于d表上没有yh_id的索引，索引在d表上添加索引：

alter table d add index ind_yh_id(yh_id);

执行计划：

+—-+————-+——-+——–+——————+———–+———+————–+——-+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——–+——————+———–+———+————–+——-+————-+
| 1 | SIMPLE | a | ALL | PRIMARY,INDEX_JG | NULL | NULL | NULL | 52616 | Using where |
| 1 | SIMPLE | b | ref | PRIMARY | PRIMARY | 98 | test.a.JG_ID | 1 | Using index |
| 1 | SIMPLE | c | eq_ref | PRIMARY | PRIMARY | 98 | test.b.YH_ID | 1 | Using where |
| 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.b.YH_ID | 272 | Using index |
+—-+————-+——-+——–+——————+———–+———+————–+——-+————-+

执行时间：

1 row in set (0.77 sec)

在d表上添加索引后，d表的扫描行数下降到272行（最开始为：54584 ）

| 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.b.YH_ID | 272 | Using index |

第二阶段：c表作为驱动表

d
^
|
c–>b–>a
由于在c表上有yh_dm过滤性很高的筛选条件，所以我们在yh_dm上创建一个索引：

mysql> select count(*) from c where yh_dm = '006939748XX';
+———-+
| count(*) |
+———-+
| 2 |
+———-+

添加索引：

alter table c add index ind_yh_dm(yh_dm)

查看执行计划：

+—-+————-+——-+——–+——————-+———–+———+————–+——-+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——–+——————-+———–+———+————–+——-+————-+
| 1 | SIMPLE | a | ALL | PRIMARY,INDEX_JG | NULL | NULL | NULL | 52616 | Using where |
| 1 | SIMPLE | b | ref | PRIMARY | PRIMARY | 98 | test.a.JG_ID | 1 | Using index |
| 1 | SIMPLE | c | eq_ref | PRIMARY,ind_yh_dm | PRIMARY | 98 | test.b.YH_ID | 1 | Using where |
| 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.b.YH_ID | 272 | Using index |
+—-+————-+——-+——–+——————-+———–+———+————–+——-+————-+

执行时间：

1 row in set (0.74 sec)

在c表上添加索引后，索引还是没有走上，执行计划还是以a表作为驱动表，所以我们这里来分析一下为什么还是以a表作为驱动表？

1):c.yh_id=b.yh_id—>( PRIMARY KEY (`JG_ID`,`YH_ID`) )

a.如果以c表为驱动表，则c表与b表在关联的时候，由于在b表没有yh_id字段的索引，由于b表的数据量很大，所以优化器认为这里如果以c表作为驱动表，则会与b表产生较大的关联（这里可以使用straight_join强制使用c表作为驱动表）；
b.如果以a表为驱动表，则a表与b表在关联的时候，由于在b表上有jg_id字段的索引，所以优化器认为以a作为驱动表的代价是小于以c作为驱动板的代价；
所以我们如果要以C表为驱动表，只需要在b上添加yh_id的索引：

alter table b add index ind_yh_id(yh_id);

2):b.jg_id=a.jg_id—>( PRIMARY KEY (`JG_ID`) )

3):c.yh_id=d.yh_id—>( KEY `ind_yh_id` (`YH_ID`) )
执行计划：

+—-+————-+——-+——–+——————-+———–+———+————–+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——–+——————-+———–+———+————–+——+————-+
| 1 | SIMPLE | c | ref | PRIMARY,ind_yh_dm | ind_yh_dm | 57 | const | 2 | Using where |
| 1 | SIMPLE | d | ref | ind_yh_id | ind_yh_id | 98 | test.c.YH_ID | 272 | Using index |
| 1 | SIMPLE | b | ref | PRIMARY,ind_yh_id | ind_yh_id | 98 | test.c.YH_ID | 531 | Using index |
| 1 | SIMPLE | a | eq_ref | PRIMARY,INDEX_JG | PRIMARY | 98 | test.b.JG_ID | 1 | Using where |
+—-+————-+——-+——–+——————-+———–+———+————–+——+————-+

执行时间：

1 row in set (0.00 sec)

可以看到执行计划中的rows已经大大降低，执行时间也由原来的750ms降低到0 ms级别；

您可能感兴趣的文章:

MySQL

select into from和insert into select的使用举例详解
select into from和insert into select都是用来复制表,下面这篇文章主要给大家介绍了关于select into from和insert into select使用的相关资料,文中通过实例代码介绍的非常详细,需要的朋友可以参考下
2023-04-04
Navicat连接MySQL提示1045错误解决(重置MySQL密码)
连接MySQL数据库时难免会遇到1045错误,主要是因为用户输入的用户名或密码错误被拒绝访问,如果不想重装,需要找回密码或者重置密码,这篇文章主要给大家介绍了关于Navicat连接MySQL提示1045错误解决的方法,主要是重置MySQL密码,需要的朋友可以参考下
2023-04-04
MySQL慢SQL语句常见诱因以及解决方法
在本篇文章里小编给大家整理的关于MySQL慢SQL语句常见诱因以及解决方法，有需要的朋友们可以学习下。
2019-08-08
详解MySQL kill 指令的执行原理
这篇文章主要介绍了详解MySQL kill 指令的执行原理，帮助大家更好的理解和学习使用MySQL，感兴趣的朋友可以了解下
2021-03-03
Mysql数据库慢查询常用优化方式
数据库SQL优化是老生常谈的问题,下面这篇文章主要给大家介绍了关于Mysql数据库慢查询常用优化方式,文中通过实例代码介绍的非常详细,需要的朋友可以参考下
2023-05-05
MySQL 外键约束和表关系相关总结
一个项目中如果将所有的数据都存放在一张表中是不合理的，比如一个员工信息，公司只有2个部门，但是员工有1亿人，就意味着员工信息这张表中的部门字段的值需要重复存储，极大的浪费资源，因此可以定义一个部门表和员工信息表进行关联，而关联的方式就是外键。
2021-06-06
Mysql多层子查询示例代码(收藏夹案例)
这篇文章主要介绍了Mysql多层子查询示例代码，以收藏夹案例给大家详细介绍，代码简单易懂，对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
2022-03-03
Mysql给普通分页查询结果加序号实操
这篇文章主要介绍了Mysql给普通分页查询结果加序号实操，文章通过围绕主题展开详细的内容介绍，具有一定的参考价值，需要的小伙伴可以参考一下
2022-09-09
ubuntu16.04.1下 mysql安装和卸载图文教程
这篇文章主要介绍了ubuntu16.04.1下 mysql安装和卸载图文教程,非常不错，具有参考借鉴价值，需要的朋友可以参考下
2016-11-11
MySQL联结表介绍以及使用详解
这篇文章主要给大家介绍了关于MySQL联结表介绍及使用的相关资料,联结SQL最强大的功能之一就是能在数据检索查询的执行中联结表,文中通过代码介绍的非常详细,需要的朋友可以参考下
2024-03-03