在2010年，我会加入这个问题的作者，并强烈地投票给JOIN，但有了更多的经验(特别是在MySQL)，我可以声明:是的，子查询可以更好。我在这里看到了很多答案;一些声明的子查询速度更快，但它缺乏一个很好的解释。我希望我能提供一个(非常)晚的答案:

首先，让我说一下最重要的一点:子查询有不同的形式

第二个重要的陈述:规模很重要

如果使用子查询，应该了解DB-Server如何执行子查询。特别是当子查询只计算一次或每一行时! 另一方面，现代DB-Server能够进行大量优化。在某些情况下，子查询有助于优化查询，但DB-Server的新版本可能会使优化过时。

选择字段中的子查询

SELECT moo, (SELECT roger FROM wilco WHERE moo = me) AS bar FROM foo

注意，对于foo生成的每一行都会执行子查询。 尽可能避免这种情况;它可能会大大降低你在大型数据集上的查询速度。但是，如果子查询没有对foo的引用，则可以由DB-server将其作为静态内容进行优化，并且只能求值一次。

where语句中的子查询

SELECT moo FROM foo WHERE bar = (SELECT roger FROM wilco WHERE moo = me)

如果幸运的话，DB会在内部将其优化为一个JOIN。如果不这样做，你的查询在庞大的数据集上会变得非常非常慢，因为它会对foo中的每一行执行子查询，而不是像在select类型中那样只执行结果。

join语句中的子查询

SELECT moo, bar 
  FROM foo 
    LEFT JOIN (
      SELECT MIN(bar), me FROM wilco GROUP BY me
    ) ON moo = me

This is interesting. We combine JOIN with a sub-query. And here we get the real strength of sub-queries. Imagine a dataset with millions of rows in wilco but only a few distinct me. Instead of joining against a huge table, we have now a smaller temporary table to join against. This can result in much faster queries depending on database size. You can have the same effect with CREATE TEMPORARY TABLE ... and INSERT INTO ... SELECT ..., which might provide better readability on very complex queries (but can lock datasets in a repeatable read isolation level).

嵌套的子查询

SELECT VARIANCE(moo)
  FROM (
    SELECT moo, CONCAT(roger, wilco) AS bar
      FROM foo
      HAVING bar LIKE 'SpaceQ%'
  ) AS temp_foo
  GROUP BY moo

您可以在多个级别中嵌套子查询。如果你必须对结果进行分组或更改，这可以帮助处理庞大的数据集。通常，DB-Server为此创建一个临时表，但有时不需要对整个表进行某些操作，只需要对结果集进行操作。这可能会提供更好的性能，具体取决于表的大小。

结论

子查询不能代替JOIN，您不应该这样使用它们(尽管有可能)。在我看来，子查询的正确用法是作为CREATE TEMPORARY TABLE ....的快速替换一个好的子查询以一种在JOIN的ON语句中无法完成的方式减少数据集。如果子查询具有GROUP BY或DISTINCT关键字之一，并且最好不在选择字段或where语句中，那么它可能会大大提高性能。

在旧Mambo CMS的一个非常大的数据库上运行:

SELECT id, alias
FROM
  mos_categories
WHERE
  id IN (
    SELECT
      DISTINCT catid
    FROM mos_content
  );

0秒

SELECT
  DISTINCT mos_content.catid,
  mos_categories.alias
FROM
  mos_content, mos_categories
WHERE
  mos_content.catid = mos_categories.id;

~ 3秒

EXPLAIN说明它们检查的行数完全相同，但其中一个需要3秒，另一个几乎是即时的。这个故事的寓意?如果性能很重要(什么时候不重要?)，尝试多种方法，看看哪一种最快。

和…

SELECT
  DISTINCT mos_categories.id,
  mos_categories.alias
FROM
  mos_content, mos_categories
WHERE
  mos_content.catid = mos_categories.id;

0秒

同样，结果相同，检查的行数相同。我猜是DISTINCT mos_content。catid比DISTINCT mos_categories需要更长的时间来计算。id。

子查询是解决“从A获取事实，以B的事实为条件”这种形式的问题的逻辑正确方法。在这种情况下，在子查询中插入B比进行连接更具逻辑意义。从实际意义上讲，它也更安全，因为您不必担心由于与B的多个匹配而从a获得重复的事实。

然而，实际上，答案通常归结于性能。当给出连接和子查询时，一些优化器会很糟糕，而另一些则相反，这是特定于优化器、特定于dbms版本和特定于查询的。

从历史上看，显式连接通常会胜出，因此已经建立的智慧是连接更好，但优化器一直在变得更好，因此我更喜欢先以逻辑一致的方式编写查询，然后在性能限制的情况下重新构造查询。

现在，许多dbs都可以优化子查询和连接。因此，您只需使用explain检查您的查询，看看哪个更快。如果在性能上没有太大的差异，我更喜欢使用子查询，因为它们简单，更容易理解。

我认为在引用的答案中没有强调的是重复的问题和可能由特定(使用)案例引起的有问题的结果。

(尽管马塞洛·坎托斯提到过)

我将引用斯坦福大学Lagunita SQL课程的例子。

学生表

+------+--------+------+--------+
| sID  | sName  | GPA  | sizeHS |
+------+--------+------+--------+
|  123 | Amy    |  3.9 |   1000 |
|  234 | Bob    |  3.6 |   1500 |
|  345 | Craig  |  3.5 |    500 |
|  456 | Doris  |  3.9 |   1000 |
|  567 | Edward |  2.9 |   2000 |
|  678 | Fay    |  3.8 |    200 |
|  789 | Gary   |  3.4 |    800 |
|  987 | Helen  |  3.7 |    800 |
|  876 | Irene  |  3.9 |    400 |
|  765 | Jay    |  2.9 |   1500 |
|  654 | Amy    |  3.9 |   1000 |
|  543 | Craig  |  3.4 |   2000 |
+------+--------+------+--------+

应用表

(向特定大学及专业申请)

+------+----------+----------------+----------+
| sID  | cName    | major          | decision |
+------+----------+----------------+----------+
|  123 | Stanford | CS             | Y        |
|  123 | Stanford | EE             | N        |
|  123 | Berkeley | CS             | Y        |
|  123 | Cornell  | EE             | Y        |
|  234 | Berkeley | biology        | N        |
|  345 | MIT      | bioengineering | Y        |
|  345 | Cornell  | bioengineering | N        |
|  345 | Cornell  | CS             | Y        |
|  345 | Cornell  | EE             | N        |
|  678 | Stanford | history        | Y        |
|  987 | Stanford | CS             | Y        |
|  987 | Berkeley | CS             | Y        |
|  876 | Stanford | CS             | N        |
|  876 | MIT      | biology        | Y        |
|  876 | MIT      | marine biology | N        |
|  765 | Stanford | history        | Y        |
|  765 | Cornell  | history        | N        |
|  765 | Cornell  | psychology     | Y        |
|  543 | MIT      | CS             | N        |
+------+----------+----------------+----------+

让我们试着找出申请计算机科学专业的学生的平均绩点(不论大学)

使用子查询:

select GPA from Student where sID in (select sID from Apply where major = 'CS');

+------+
| GPA  |
+------+
|  3.9 |
|  3.5 |
|  3.7 |
|  3.9 |
|  3.4 |
+------+

这个结果集的平均值是:

select avg(GPA) from Student where sID in (select sID from Apply where major = 'CS');

+--------------------+
| avg(GPA)           |
+--------------------+
| 3.6800000000000006 |
+--------------------+

使用连接:

select GPA from Student, Apply where Student.sID = Apply.sID and Apply.major = 'CS';

+------+
| GPA  |
+------+
|  3.9 |
|  3.9 |
|  3.5 |
|  3.7 |
|  3.7 |
|  3.9 |
|  3.4 |
+------+

该结果集的平均值:

select avg(GPA) from Student, Apply where Student.sID = Apply.sID and Apply.major = 'CS';

+-------------------+
| avg(GPA)          |
+-------------------+
| 3.714285714285714 |
+-------------------+

It is obvious that the second attempt yields misleading results in our use case, given that it counts duplicates for the computation of the average value. It is also evident that usage of distinct with the join - based statement will not eliminate the problem, given that it will erroneously keep one out of three occurrences of the 3.9 score. The correct case is to account for TWO (2) occurrences of the 3.9 score given that we actually have TWO (2) students with that score that comply with our query criteria.

在某些情况下，除了性能问题，子查询似乎是最安全的方法。

MSDN文档SQL Server说

Many Transact-SQL statements that include subqueries can be alternatively formulated as joins. Other questions can be posed only with subqueries. In Transact-SQL, there is usually no performance difference between a statement that includes a subquery and a semantically equivalent version that does not. However, in some cases where existence must be checked, a join yields better performance. Otherwise, the nested query must be processed for each result of the outer query to ensure elimination of duplicates. In such cases, a join approach would yield better results.

所以如果你需要

select * from t1 where exists select * from t2 where t2.parent=t1.id

尝试使用join代替。在其他情况下，这没有什么区别。

我说:为子查询创建函数可以消除混乱的问题，并允许您为子查询实现额外的逻辑。因此，我建议尽可能为子查询创建函数。

代码中的混乱是一个大问题，几十年来业界一直在努力避免它。