sql - 避免嵌套查询

Question

避免嵌套查询有多重要。

我总是学会像躲避瘟疫一样避开它们。但它们对我来说是最自然的。当我设计一个查询时，我写的第一件事就是嵌套查询。然后我将其转换为连接，这有时需要很长时间才能正确。并且很少能带来很大的性能提升(有时确实如此)

他们真的那么糟糕吗？有没有办法在没有临时表和文件排序的情况下使用嵌套查询

Answer 1

这真的取决于，我曾遇到过使用子查询改进某些查询的情况。

我知道的因素是:

• 子查询是否使用外部查询的字段进行比较(correlated 或不)
• 如果外层查询和子查询之间的关系被索引覆盖
• 如果连接上没有可用的索引并且子查询不相关并且返回的结果很小，那么使用它可能会更快
• 我也遇到过将使用 order by 的查询转换为不使用它的查询，而不是将其转换为简单的子查询和排序以提高 mysql 性能的情况

无论如何，测试不同的变体总是好的(请使用 SQL_NO_CACHE)，将相关查询转换为连接是一个很好的做法。

我什至可以称其为非常有用的实践。

如果相关查询是您首先想到的，那么您可能不是主要考虑集合操作，而是主要考虑过程操作，并且在处理关系数据库时，完全了解它非常有用对数据模型及其转换采用集合视角。

编辑:程序与关系
在集合运算与过程方面的思考归结为某些集合代数表达式中的等价性，例如并集上的选择等同于选择的并集。两者没有区别。
但是，当您比较这两个过程时，例如将选择标准应用到一个联合的每个元素并创建一个联合，然后应用选择，这两个是截然不同的过程，它们可能具有非常不同的属性(例如 CPU 利用率，我/O，内存)。

关系型数据库背后的思想是，你不要试图描述如何得到结果(过程)，而只是描述你想要什么，数据库管理系统将决定最佳路径(过程)来满足你的请求.这就是 SQL 被称为 4th generation language (4GL) 的原因.

帮助您做到这一点的技巧之一是提醒自己元组没有内在顺序(集合元素是无序的)。另一个是意识到关系代数非常全面并且允许将请求(需求)直接翻译成 SQL(如果你的模型的语义很好地代表了问题空间，或者换句话说，如果正确地附加到你的表和关系的名称的含义，或者换句话说，如果您的数据库设计良好)。

因此，您不必考虑如何，只需考虑什么。

在您的情况下，这只是对相关查询的偏好，所以我可能没有告诉您任何新内容，但您强调了这一点，因此发表了评论。

我认为，如果您完全熟悉将查询从一种形式转换为另一种形式的所有规则(rules，例如分布式)，您就不会更喜欢相关的子查询(您会看到所有形式都是平等的)。

(注意:上面讨论了对数据库设计很重要的理论背景；实际上，上述概念有所不同——并非所有等效的查询重写都必须执行得那么快，聚簇主键确实使表在磁盘上具有继承顺序，等等。 . 但这些偏差只是偏差；并非所有等效查询都执行得那么快这一事实是实际 DBMS 的缺陷，而不是其背后的概念)