避免嵌套查询有多重要。
我一直学会避免像瘟疫一样躲避它们。但是对我来说，它们是最自然的事情。在设计查询时，我首先写的是嵌套查询。然后，我将其转换为联接，有时需要花费很多时间才能正确。而且很少会带来很大的性能提升(有时确实会提高)
他们真的那么糟糕吗？有没有一种方法可以使用没有临时表和文件排序的嵌套查询
最佳答案
这确实取决于我遇到的情况，我可以通过使用子查询来改进一些查询。
我知道的因素有:
无论如何，测试不同的变体(请使用SQL_NO_CACHE)总是好的，将相关查询转换为联接是一个好习惯。
我什至会称其为非常有用的做法。
如果您首先想到了相关查询，则可能不是您主要考虑集合操作，而是考虑过程操作以及处理关系数据库时，完全采用集合是非常有用的数据模型的观点及其转换。
编辑:
程序vs关系
在一些集合代数表达式中，根据集合运算与过程的思考可以归结为对等，例如，对一个并集的选择等同于选择的并集。两者之间没有区别。
但是，当您比较这两个过程时，例如将选择标准应用到具有make union的并集的每个元素上，然后应用选择，则这两个过程是截然不同的过程，它们可能具有非常不同的属性(例如，CPU利用率，I / O，内存)。
关系数据库背后的想法是，您不会尝试描述如何获得结果(过程)，而只是描述您想要的结果，并且数据库管理系统将决定满足您请求的最佳路径(过程)。这就是为什么SQL称为4th generation language (4GL)的原因。
可以帮助您做到这一点的技巧之一是提醒自己，元组没有固有的顺序(集合元素是无序的)。
另一个人意识到关系代数非常全面，并且可以将请求(要求)直接转换为SQL(如果模型的语义很好地表示了问题空间，或者换句话说，如果表和关系的名称附带的含义正确完成) ，换句话说，如果您的数据库设计合理)。
因此，您不必思考如何，只需思考什么。
在您的情况下，它只是优先于相关查询，所以可能我没有告诉您任何新内容，但您强调了这一点，因此是评论。
我认为，如果您完全满意将查询从一种形式转换为另一种形式的所有规则(诸如分布性的rules)，则您将不希望使用关联子查询(所有形式都相等)。
(注意:上面讨论了理论背景，对于数据库设计很重要;实际上上述概念有所不同-并非所有等效的查询重写都必须以快速执行，因为集群主键确实会使表在磁盘上具有继承顺序，等等..偏差只是偏差；并非所有等效查询都执行得这么快的事实是实际DBMS的缺陷，而不是其背后的概念)
关于sql - 避免嵌套查询，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2778791/