再谈MySQL的子查询优化技术

朋友说:

我这几天看了子查询的课程以及查阅了一些资料，给我的感受是
子查询不怎么好使，能不用就尽量不用，做过的项目很少采用子查询，很多相关子查询都可以上拉至连接查询。
稍微用的多一点的可能就是IN查询了

 

答复:
---1 技术是通用的---通常都是上拉优化的思路,一个概述可以参见:http://blog.163.com/li_hx/blog/static/18399141320142239359546/.
---2 你这种感受, 可以从2个角度解释：
---2.1 技术角度：从技术上看
---MySQL的子查询优化，有其独到之处，主要表现在他把子查询优化分为几个阶段（去不必要的冗余子句、将IN/ALL/ANY等类型的子查询转换为MIN/MAX等操作，对多种形式的子查询进行支持如IN、ANY、EXISTS等，把子查询表示为物化形式或半连接以及在后期的多种半连接消重策略，以及后期用decide_subquery_strategy函数决定子查询的优化策略等；如果你感兴趣，可以参考《数据库查询优化器的艺术》第13章的子查询部分的源码分析）和几个类型（FROM子句中作为DRIVED，其他子句中作为subquery等）。细化分解，MYSQL这一点做得很好。
---MySQL的子查询优化，有其局限之处，如对其他一些子查询类型不支持（如等值的一些子查询）
---2.2 效率角度：技术好不等于效率好。这是多种原因共同决定的。比如数据库整体架构，并发控制的机制，存储架构等都影响着每一种功能。所以实践中，我们需要去检验测试才行。
---3 “能不用就尽量不用”，客观地讲，这个目前来看不是个好主意。好的做法是：首先，相信优化器能做好； 其次，SQL书写方便理解；再次，观察找出瓶颈再调优。
---毕竟我们要追求整体效率，而不光是只追求某一个SQL的效率。上线前验证好，上线后不断观测分析就行。
---当然，书写SQL时，能写出即语义明了，又不用子查询的SQL，那是最好不过了。
---另外，《数据库查询优化器的艺术》第四篇，对比了PG和MySQL的子查询优化技术，可供参考，以便进一步认识MySQL子查询技术。