浅谈 MySQL 子查询及其优化
2019独角兽企业重金招聘Python工程师标准>>>
使用过oracle或者其他关系数据库的DBA或者开发人员都有这样的经验,在子查询上都认为数据库已经做过优化,能够很好的选择驱动表执行,然后在把该经验移植到mysql数据库上,但是不幸的是,mysql在子查询的处理上有可能会让你大失所望,在我们的生产系统上就碰到过一些案例,例如:
SELECT i_id,sum(i_sell) AS i_sell
FROM table_data
WHERE i_id IN(SELECT i_idFROM table_dataWHERE Gmt_create >= '2011-10-07 00:00:00')
GROUP BY i_id;
(备注:sql的业务逻辑可以打个比方:先查询出10-07号新卖出的100本书,然后在查询这新卖出的100本书在全年的销量情况)。
这条sql之所以出现的性能问题在于mysql优化器在处理子查询的弱点,mysql优化器在处理子查询的时候,会将将子查询改写。通常情况下,我们希望由内到外,先完成子查询的结果,然后在用子查询来驱动外查询的表,完成查询;但是mysql处理为将会先扫描外面表中的所有数据,每条数据将会传到子查询中与子查询关联,如果外表很大的话,那么性能上将会出现问题;
针对上面的查询,由于table_data这张表的数据有70W的数据,同时子查询中的数据较多,有大量是重复的,这样就需要关联近70W次,大量的关联导致这条sql执行了几个小时也没有执行完成,所以我们需要改写sql:
SELECT t2.i_id,SUM(t2.i_sell) AS sold
FROM(SELECT DISTINCT i_idFROM table_dataWHERE gmt_create >= '2011-10-07 00:00:00') t1,table_data t2
WHERE t1.i_id = t2.i_id
GROUP BY t2.i_id;
我们将子查询改为了关联,同时在子查询中加上distinct,减少t1关联t2的次数;
改造后,sql的执行时间降到100ms以内。
mysql的子查询的优化一直不是很友好,一直有受业界批评比较多,也是我在sql优化中遇到过最多的问题之一,mysql在处理子查询的时候,会将子查询改写,通常情况下,我们希望由内到外,也就是先完成子查询的结果,然后在用子查询来驱动外查询的表,完成查询,但是恰恰相反,子查询不会先被执行;今天希望通过介绍一些实际的案例来加深对mysql子查询的理解。下面将介绍一个完整的案例及其分析、调优的过程与思路。
1、案例:
用户反馈数据库响应较慢,许多业务动更新被卡住;登录到数据库中观察,发现长时间执行的sql;
| 10437 | usr0321t9m9 | 10.242.232.50:51201 | oms | Execute | 1179 | SendingSql为:SELECT tradedto0_.*
FROM a1 tradedto0_
WHERE tradedto0_.tradestatus='1'AND (tradedto0_.tradeoid IN(SELECT orderdto1_.tradeoidFROM a2 orderdto1_WHERE orderdto1_.proname LIKE '%??%'OR orderdto1_.procode LIKE '%??%'))AND tradedto0_.undefine4='1'AND tradedto0_.invoicetype='1'AND tradedto0_.tradestep='0'AND (tradedto0_.orderCompany LIKE '0002%')
ORDER BY tradedto0_.tradesign ASC,tradedto0_.makertime DESC LIMIT 15;
2、现象:其他表的更新被阻塞
UPDATE a1
SET tradesign='DAB67634-795C-4EAC-B4A0-78F0D531D62F',markColor=' #CD5555',memotime='2012-09- 22',markPerson='??'
WHERE tradeoid IN ('gy2012092204495100032') ;
为了尽快恢复应用,将其长时间执行的sql kill掉后,应用恢复正常;
3、分析执行计划:
db@3306 :explain
SELECT tradedto0_.*
FROM a1 tradedto0_
WHERE tradedto0_.tradestatus='1'AND (tradedto0_.tradeoid IN(SELECT orderdto1_.tradeoidFROM a2 orderdto1_WHERE orderdto1_.proname LIKE '%??%'OR orderdto1_.procode LIKE '%??%'))AND tradedto0_.undefine4='1'AND tradedto0_.invoicetype='1'AND tradedto0_.tradestep='0'AND (tradedto0_.orderCompany LIKE '0002%')
ORDER BY tradedto0_.tradesign ASC,tradedto0_.makertime DESC LIMIT 15;+----+--------------------+------------+------+---------------+------+---------+------+-------+-----
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+------------+------+---------------+------+---------+------+-------+-----
| 1 | PRIMARY | tradedto0_ | ALL | NULL | NULL | NULL | NULL | 27454 | Using where; Using filesort |
| 2 | DEPENDENT SUBQUERY | orderdto1_ | ALL | NULL | NULL | NULL | NULL | 40998 | Using where |
+----+--------------------+------------+------+---------------+------+---------+------+-------+-----
从执行计划上,我们开始一步一步地进行优化:
首先,我们看看执行计划的第二行,也就是子查询的那部分,orderdto1_进行了全表的扫描,我们看看能不能添加适当的索引:
A . 使用覆盖索引:
db@3306:alter table a2 add index ind_a2(proname,procode,tradeoid);
ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes
添加组合索引超过了最大key length限制:
B.查看该表的字段定义:
db@3306 :DESC a2 ;
+---------------------+---------------+------+-----+---------+-------+
| FIELD | TYPE | NULL | KEY | DEFAULT | Extra |
+---------------------+---------------+------+-----+---------+-------+
| OID | VARCHAR(50) | NO | PRI | NULL | |
| TRADEOID | VARCHAR(50) | YES | | NULL | |
| PROCODE | VARCHAR(50) | YES | | NULL | |
| PRONAME | VARCHAR(1000) | YES | | NULL | |
| SPCTNCODE | VARCHAR(200) | YES | | NULL | |
C.查看表字段的平均长度:
db@3306 :SELECT MAX(LENGTH(PRONAME)),avg(LENGTH(PRONAME)) FROM a2;
+----------------------+----------------------+
| MAX(LENGTH(PRONAME)) | avg(LENGTH(PRONAME)) |
+----------------------+----------------------+
| 95 | 24.5588 |
D.缩小字段长度
ALTER TABLE MODIFY COLUMN PRONAME VARCHAR(156);
再进行执行计划分析:
db@3306 :explain
SELECT tradedto0_.*
FROM a1 tradedto0_
WHERE tradedto0_.tradestatus='1'AND (tradedto0_.tradeoid IN(SELECT orderdto1_.tradeoidFROM a2 orderdto1_WHERE orderdto1_.proname LIKE '%??%'OR orderdto1_.procode LIKE '%??%'))AND tradedto0_.undefine4='1'AND tradedto0_.invoicetype='1'AND tradedto0_.tradestep='0'AND (tradedto0_.orderCompany LIKE '0002%')
ORDER BY tradedto0_.tradesign ASC,tradedto0_.makertime DESC LIMIT 15;+----+--------------------+------------+-------+-----------------+----------------------+---------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+------------+-------+-----------------+----------------------+---------+
| 1 | PRIMARY | tradedto0_ | ref | ind_tradestatus | ind_tradestatus | 345 | const,const,const,const | 8962 | Using where; Using filesort |
| 2 | DEPENDENT SUBQUERY | orderdto1_ | index | NULL | ind_a2 | 777 | NULL | 41005 | Using where; Using index |
+----+--------------------+------------+-------+-----------------+----------------------+---------+
发现性能还是上不去,关键在两个表扫描的行数并没有减小(8962*41005),上面添加的索引没有太大的效果,现在查看t表的执行结果:
db@3306 :
SELECT orderdto1_.tradeoid
FROM t orderdto1_
WHERE orderdto1_.proname LIKE '%??%'OR orderdto1_.procode LIKE '%??%';Empty
SET (0.05 sec)
结果集为空,所以需要将t表的结果集做作为驱动表;
4、改写子查询:
通过上面测试验证,普通的mysql子查询写法性能上是很差的,为mysql的子查询天然的弱点,需要将sql进行改写为关联的写法:
SELECT tradedto0_.*
FROM a1 tradedto0_ ,(SELECT orderdto1_.tradeoidFROM a2 orderdto1_WHERE orderdto1_.proname LIKE '%??%'OR orderdto1_.procode LIKE '%??%')t2
WHERE tradedto0_.tradestatus='1'AND (tradedto0_.tradeoid=t2.tradeoid)AND tradedto0_.undefine4='1'AND tradedto0_.invoicetype='1'AND tradedto0_.tradestep='0'AND (tradedto0_.orderCompany LIKE '0002%')
ORDER BY tradedto0_.tradesign ASC,tradedto0_.makertime DESC LIMIT 15;
5、查看执行计划:
db@3306 :explain
SELECT tradedto0_.*
FROM a1 tradedto0_ ,(SELECT orderdto1_.tradeoidFROM a2 orderdto1_WHERE orderdto1_.proname LIKE '%??%'OR orderdto1_.procode LIKE '%??%')t2
WHERE tradedto0_.tradestatus='1'AND (tradedto0_.tradeoid=t2.tradeoid)AND tradedto0_.undefine4='1'AND tradedto0_.invoicetype='1'AND tradedto0_.tradestep='0'AND (tradedto0_.orderCompany LIKE '0002%')
ORDER BY tradedto0_.tradesign ASC,tradedto0_.makertime DESC LIMIT 15;+----+-------------+------------+-------+---------------+----------------------+---------+------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+-------+---------------+----------------------+---------+------+
| 1 | PRIMARY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | Impossible WHERE noticed after reading const tables |
| 2 | DERIVED | orderdto1_ | index | NULL | ind_a2 | 777 | NULL | 41005 | Using where; Using index |
+----+-------------+------------+-------+---------------+----------------------+---------+------+
6、执行时间:
db@3306 :
SELECT tradedto0_.*
FROM a1 tradedto0_ ,(SELECT orderdto1_.tradeoidFROM a2 orderdto1_WHERE orderdto1_.proname LIKE '%??%'OR orderdto1_.procode LIKE '%??%')t2
WHERE tradedto0_.tradestatus='1'AND (tradedto0_.tradeoid=t2.tradeoid)AND tradedto0_.undefine4='1'AND tradedto0_.invoicetype='1'AND tradedto0_.tradestep='0'AND (tradedto0_.orderCompany LIKE '0002%')
ORDER BY tradedto0_.tradesign ASC,tradedto0_.makertime DESC LIMIT 15;Empty
SET (0.03 sec)
缩短到了毫秒;
7、总结:
1. mysql子查询在执行计划上有着明显的弱点,需要将子查询进行改写
可以参考:
a. 生产库中遇到mysql的子查询:http://hidba.org/?p=412
b. 内建的builtin InnoDB,子查询阻塞更新:http://hidba.org/?p=456
2. 在表结构设计上,不要随便使用varchar(N)的大字段,导致无法使用索引
可以参考:
a. JDBC内存管理—varchar2(4000)的影响:http://hidba.org/?p=31
b. innodb中大字段的限制:http://hidba.org/?p=144
c. innodb使用大字段text,blob的一些优化建议: http://hidba.org/?p=551
8、Refer:
[1] 生产库中遇到mysql的子查询 http://hidba.org/?p=412
[2] 浅谈mysql的子查询 http://hidba.org/?p=624
[3] mysql子查询的弱点 http://hidba.org/?p=260
转载于:https://my.oschina.net/leejun2005/blog/288533
浅谈 MySQL 子查询及其优化相关推荐
- js 递归查询所有的叶子结点_浅谈mysql的查询过程
步骤 查询过程上看,大致步骤如下: 查看缓存中是否存在id 如果有则从内存中访问,否则要访问磁盘 将索引数据存入内存,利用索引来访问数据 对于数据也会检查数据是否存在于内存 如果没有则访问磁盘获取数据 ...
- 浅谈MySQL连接查询与外键
连接查询是同时查询多张表,通过多张表之间的关系得到最终的结果.连接查询又分成内连接.外链接和自然连接. 内连接:从左表中取出每一条记录,去右表中与所有的记录进行匹配;匹配必须是某个条件在左表中与右表中 ...
- MySQL子查询的优缺点_浅谈mysql的子查询
浅谈mysql的子查询 mysql的子查询的优化一直不是很友好,一直有受业界批评比较多,也是我在sql优化中遇到过最多的问题之一,你可以点击这里 ,这里来获得一些信息,mysql在处理子查询的时候,会 ...
- 浅谈mysql的子查询
2019独角兽企业重金招聘Python工程师标准>>> mysql的子查询的优化一直不是很友好,一直有受业界批评比较多,也是我在sql优化中遇到过最多的问题之一,mysql在处理子查 ...
- 浅谈MySQL的B树索引与索引优化
转载自 浅谈MySQL的B树索引与索引优化 MySQL的MyISAM.InnoDB引擎默认均使用B+树索引(查询时都显示为"BTREE"),本文讨论两个问题: 为什么MySQL ...
- 【转载】运维角度浅谈MySQL数据库优化
运维角度浅谈MySQL数据库优化 2015-06-02 14:22:02 标签:mysql优化 mysql分库分表分区 mysql读写分离 mysql主从复制 原创作品,允许转载,转载时请务必以 ...
- mysql子查询缺点_[慢查优化]慎用MySQL子查询,尤其是看到DEPENDENT SUBQUERY标记时
它的执行计划如下,请注意看关键词"DEPENDENT SUBQUERY": id select_type table type poss ...
- mysql in 子查询优化_mysql in 子查询 容易优化
mysql in 子查询 简单优化 大数量下,不要使用 in 嵌套子查询,性能很差,很容易卡死. ? 简单调整方式如下: select uid,nick_name from uc_users wher ...
- Mysql 关联查询的优化 及 子查询优化
Mysql 关联查询的优化 left join ①EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card; ②如何优化 ...
最新文章
- CentOS环境搭建
- scanf 输入十六进制_在C语言中使用scanf()输入一个十六进制值
- MySQL数据的备份与还原实现步骤
- python成绩统计_python统计考试成绩代码参考
- 024、JVM实战总结:动手实验:线上部署系统时,如何设置垃圾回收相关参数?
- 计算机二级c语言编程题型,全国计算机等级二级C语言上机编程题题型
- Oracle中删除重复记录
- 计算机械加工工时都需要,机械加工工时(工时定额)计算软件
- Hyperledger Fabric 2.x Java区块链应用
- 往事如烟 - 高手老胡
- Java执行Excel公式
- 183 25用计算机算列竖式,新北师大四年级上册数学计算题
- 网页上简体繁体汉字切换
- 利用python requests库模拟登陆知乎
- qrect在图片上显示矩形框_2019年6月百度大脑产品上新技术升级盘点内容
- 用javascript编写网页:1.2css实践:页面布局
- 【金融证券】证券基础之股债基
- 毛毛最新推荐伤感日志:我是一个任性的孩子
- 网络拓扑设计----hcip
- IDEALENS K2亮相北京,被现场试用者称为佩戴最舒适的VR产品
热门文章
- ibm刀片服务器虚拟化,IBM POWER刀片服务器的虚拟化解决方案v1.3.ppt
- python解复杂方程_Python数据处理篇之Sympy系列(五)---解方程
- 《深入理解Java虚拟机》(第二版)学习2:垃圾收集算法
- 网络编程 UDP通信的过程 TCP通信过程 多线程文件上传
- python入门小练习_python入门题目小练
- python 虚拟现实_虚拟现实 | MOOC中国 - 慕课改变你,你改变世界
- 12-flutter Textfield的使用
- 你真的会用 CocoaPods 吗?
- Storybook 5.0正式发布:有史以来变化最大的版本\n
- [UWP] 用 AudioGraph 来增强 UWP 的音频处理能力——AudioFrameInputNode