MySQL SQL优化:关联子查询的局限性

这是MySQL SQL优化的第三篇。

公司某个业务系统频繁抛出问题SQL,我们对此类SQL做了基本面统计:

此类SQL近期共执行了12次,最长一次花费480秒,最短286秒

t1表的rows有90多万,始终会扫描这么多不需要的数据

这是由于MySQL查询优化器在处理相关子查询方面存在局限性

MySQL总是会将相关的外层表压到子查询中,它认为这可以更高效地查找数据行。
这就意味着MySQL先选择对外层表进行全表扫描,然后根据相关字段一个一个执行子查询,

如果是个小表,情况可能还不会引起我们注意,但是如果外层表示一个非常大的表,那么这个查询的性能会非常槽糕,

很不幸,我们的场景刚好应了后者


我们优化后的执行效果:




Good Luck!

<!-- Baidu Button BEGIN --&gt <

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26515977/viewspace-1208268/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/26515977/viewspace-1208268/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值