首页 / MYSQL / mysql 子查询和联合查询
mysql 子查询和联合查询
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了mysql 子查询和联合查询,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含7434字,纯文字阅读大概需要11分钟。
内容图文
![mysql 子查询和联合查询](/upload/InfoBanner/zyjiaocheng/523/ce41c5008502473f91b8a1075b302932.jpg)
在实例讲解之前,我们先回顾一下联表查询的基础知识。
——联表查询的基础知识——
引子:为什么第一个查询using temporary,第二个查询不用临时表呢?
下面两个查询,它们只差了一个order by,效果却迥然不同。
第一个查询:
EXPLAIN extended
SELECT ads.id
FROM ads, city
WHERE
city.city_id = 8005
AND ads.status = ‘online‘
AND city.ads_id=ads.id
ORDER BY ads.id desc
执行计划为:
id select_type table type possible_keys key key_len ref rows filtered Extra
------ ----------- ------ ------ -------------- ------- ------- -------------------- ------ -------- -------------------------------
1 SIMPLE city ref ads_id,city_id city_id 4 const 2838 100.00 Using temporary; Using filesort
1 SIMPLE ads eq_ref PRIMARY PRIMARY 4 city.ads_id 1 100.00 Using where
第二个查询:
执行计划里没有了using temporary: id select_type table type possible_keys key key_len ref rows filtered ExtraEXPLAIN extended
SELECT ads.id
FROM ads,city
WHERE
city.city_id =8005
AND ads.status = ‘online‘
AND city.ads_id=ads.id
ORDER BY city.ads_id desc
------ ----------- ------ ------ -------------- ------- ------- -------------------- ------ -------- ---------------------------
1 SIMPLE city ref ads_id,city_id city_id 4 const 2838 100.00 Using where; Using filesort
1 SIMPLE ads eq_ref PRIMARY PRIMARY 4 city.ads_id 1 100.00 Using where 为什么? DBA告诉我们: MySQL 表关联的算法是 Nest Loop Join,是通过驱动表的结果集作为循环基础数据,然后一条一条地通过该结果集中的数据作为过滤条件到下一个表中查询数据,然后合并结果。 EXPLAIN 结果中,第一行出现的表就是驱动表(Important!) 以上两个查询语句,驱动表都是 city,如上面的执行计划所示! 对驱动表可以直接排序,对非驱动表(的字段排序)需要对循环查询的合并结果(临时表)进行排序(Important!) 因此,order by ads.id desc 时,就要先 using temporary 了! 驱动表的定义 wwh999 在 2006年总结说,当进行多表连接查询时, [驱动表] 的定义为:
1)指定了联接条件时,满足查询条件的记录行数少的表为[驱动表];
2)未指定联接条件时,行数少的表为[驱动表](Important!)。 忠告:如果你搞不清楚该让谁做驱动表、谁 join 谁,请让 MySQL 运行时自行判断 既然“未指定联接条件时,行数少的表为[驱动表]”了, 而且你也对自己写出的复杂的 Nested Loop Join 不太有把握(如下面的实例所示), 就别指定谁 left/right join 谁了, 请交给 MySQL优化器 运行时决定吧。 如果您对自己特别有信心,可以像火丁一样做优化。 小结果集驱动大结果集 de.cel 在2012年总结说,不管是你,还是 MySQL, 优化的目标是尽可能减少JOIN中Nested Loop的循环次数, 以此保证:
永远用小结果集驱动大结果集(Important!)!
——实例讲解—— Nested Loop Join慢查SQL语句 先了解一下 mb 表有 千万级记录,mbei 表要少得多。慢查实例如下:
explain SELECT mb.id, …… FROMmb LEFT JOIN mbei ON mb.id=mbei.mb_id INNER JOINu ON mb.uid=u.uid WHERE 1=1 ORDER BY mbei.apply_time DESC limit 0,10够复杂吧。Nested Loop Join 就是这样, 以驱动表的结果集作为循环的基础数据,然后将结果集中的数据作为过滤条件一条条地到下一个表中查询数据,最后合并结果;此时还有第三个表,则将前两个表的 Join 结果集作为循环基础数据,再一次通过循环查询条件到第三个表中查询数据,如此反复。 这条语句的执行计划如下: id select_type table type possible_keys key key_len ref rows Extra
------ ----------- ------ ------ -------------- -------------- ------- ------------------- ------- --------------------------------------------
1 SIMPLE mb index userid userid 4 (NULL) 6060455 Using index; Using temporary;Using filesort
1 SIMPLE mbei eq_ref mb_id mb_id 4 mb.id 1
1 SIMPLE u eq_ref PRIMARY PRIMARY 4 mb.uid 1 Using index 由于动用了“LEFT JOIN”,所以攻城狮已经指定了驱动表,虽然这张驱动表的结果集记录数达到百万级! . . 如何优化? . . 优化第一步:LEFT JOIN改为JOIN 干嘛要 left join 啊?直接 join!
explain SELECT mb.id…… FROM mb JOIN mbei ON mb.id=mbei.mb_id INNER JOINu ON mb.uid=u.uid WHERE 1=1 ORDER BY mbei.apply_time DESC limit 0,10立竿见影,驱动表立刻变为小表 mbei 了, Using temporary 消失了,影响行数少多了: id select_type table type possible_keys key key_len ref rows Extra
------ ----------- ------ ------ -------------- ------- ------- ---------------------------- ------ --------------
1 SIMPLE mbei ALL mb_id (NULL) (NULL) (NULL) 13383 Using filesort
1 SIMPLE mb eq_ref PRIMARY,userid PRIMARY 4 mbei.mb_id 1
1 SIMPLE u eq_ref PRIMARY PRIMARY 4 mb.uid 1 Using index
优化第一步之分支1:根据驱动表的字段排序,好吗? left join不变。干嘛要根据非驱动表的字段排序呢?我们前面说过“对驱动表可以直接排序,对非驱动表(的字段排序)需要对循环查询的合并结果(临时表)进行排序!”的。
explain SELECT mb.id…… FROM mb LEFT JOIN mbei ON mb.id=mbei.mb_id INNER JOINu ON mb.uid=u.uid WHERE 1=1 ORDER BY mb.id DESC limit 0,10也满足业务场景,做到了rows最小: id select_type table type possible_keys key key_len ref rows Extra
------ ----------- ------ ------ -------------- -------------- ------- ------------------- ------ -----------
1 SIMPLE mb index userid PRIMARY 4 (NULL) 10
1 SIMPLE mbei eq_ref mb_id mb_id 4 mb.id 1 Using index
1 SIMPLE u eq_ref PRIMARY PRIMARY 4 mb.uid 1 Using index
优化第二步:去除所有JOIN,让MySQL自行决定! 写这么多密密麻麻的 left join/inner join 很开心吗?
explain SELECT mb.id…… FROM mb,mbei,u立竿见影,驱动表一样是小表 mbei: id select_type table type possible_keys key key_len ref rows Extra
WHERE
mb.id=mbei.mb_id
and mb.uid=u.user_id
order by mbei.apply_time desc
limit 0,10
------ ----------- ------ ------ -------------- ------- ------- ---------------------------- ------ --------------
1 SIMPLE mbei ALL mb_id (NULL) (NULL) (NULL) 13388 Using filesort
1 SIMPLE mb eq_ref PRIMARY,userid PRIMARY 4 mbei.mb_id 1
1 SIMPLE u eq_ref PRIMARY PRIMARY 4 mb.uid 1 Using index
最后的总结: 强调再强调:
不要过于相信你的运气! 不要相信你的开发环境里SQL的执行速度! 请拿起 explain 武器, 如果你看到以下现象,请优化:https://www.cnblogs.com/zhengyun_ustc/p/slowquery1.html记住,explain 是一种美德!
- 出现了Using temporary;
- rows过多,或者几乎是全表的记录数;
- key 是 (NULL);
- possible_keys 出现过多(待选)索引。
mysql 子查询和联合查询
标签:dba order by das 需要 rom table 实例 change new
本文系统来源:https://www.cnblogs.com/heapStark/p/12818936.html
内容总结
以上是互联网集市为您收集整理的mysql 子查询和联合查询全部内容,希望文章能够帮你解决mysql 子查询和联合查询所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。