刚坐在车里就开始电闪雷鸣。听着隆隆的雷声，没有恐慌，到有几分振奋人心的舒心感、酣畅淋漓感。朝外望去，突然间，狂风夹杂着骤雨席卷而来，一泻千里。瞬间暴雨如注，打在地上，溅起朵朵浪花，在热浪的蒸腾下激起层层水雾。满大街是慌乱的人群，行人跑着、叫喊着，唧唧喳喳的赶着在房檐下躲雨。这时候伞是没有用的，挡不住狂风暴雨的袭击，无论是带了伞的，还是没带伞的，全都躲在了房檐下。
本文实例讲述了mysql关联子查询的一种优化方法。分享给大家供大家参考，具体如下：
很多时候，在mysql上实现的子查询的性能较差，这听起来实在有点难过。特别有时候，用到IN()子查询语句时，对于上了某种数量级的表来说，耗时多的难以估计。本人mysql知识所涉不深，只能慢慢摸透个中玄机了。
假设有这样的一个exists查询语句：
select * from table1 where exists (select * from table2 where id>=30000 and table1.uuid=table2.uuid);
table1为十万行级的表，table2为百万行级的表，本机测试结果用时2.40s。
通过explain可以看到子查询是一个相关子查询(DEPENDENCE SUBQUERY); Mysql会首先对外表table1进行全表扫描，然后根据返回的uuid逐次执行子查询。如果外层表是一个很大的表，我们可以想象查询性能会表现得比此次测试更糟糕。
一种简单的优化方案为使用inner join的方法来代替子查询, 查询语句则可以改为:
select * from table1 innner join table2 using(uuid) where table2.id>=30000;
本机测试结果用时0.68s。
通过explain可以看到mysql使用了SIMPLE类型(子查询或union以外的查询方式); Mysql优化器会先过滤table2，然后对table1和table2做笛卡尔积得出结果集后，再通过on条件来过滤数据。
当然了，并不是所有情况下关联子查询的性能都会差；具体效果需要进行实际的测试才能得出结果。
希望本文所述对大家MySQL数据库计有所帮助。
以上就是mysql关联子查询的一种优化方法分析。成长，本身就是一个很痛的词。你想要的或好或坏，时间都会给你。更多关于mysql关联子查询的一种优化方法分析请关注haodaima.com其它相关文章！
