子查询通常用于将单行作为原子值返回，不过它们也可以用于用IN关键字比较多行之间的值。在SQL语句中几乎任何有意义的地方都允许使用它们，包括目标列表、WHERE子句等等。一个简单的子查询可以用作搜索条件。例如，在一对表之间:

SELECT title 
FROM books 
WHERE author_id = (
    SELECT id 
    FROM authors 
    WHERE last_name = 'Bar' AND first_name = 'Foo'
);

注意，在子查询的结果上使用普通值操作符要求只返回一个字段。如果你想检查一个值是否存在于一组其他值中，请使用in:

SELECT title 
FROM books 
WHERE author_id IN (
    SELECT id FROM authors WHERE last_name ~ '^[A-E]'
);

这显然不同于LEFT-JOIN，你只是想连接表a和表B的东西，即使连接条件在表B中没有找到任何匹配的记录，等等。

如果你只是担心速度，你必须检查你的数据库，写一个好的查询，看看是否有显著的性能差异。

子查询通常用于将单行作为原子值返回，不过它们也可以用于用IN关键字比较多行之间的值。在SQL语句中几乎任何有意义的地方都允许使用它们，包括目标列表、WHERE子句等等。一个简单的子查询可以用作搜索条件。例如，在一对表之间:

SELECT title 
FROM books 
WHERE author_id = (
    SELECT id 
    FROM authors 
    WHERE last_name = 'Bar' AND first_name = 'Foo'
);

注意，在子查询的结果上使用普通值操作符要求只返回一个字段。如果你想检查一个值是否存在于一组其他值中，请使用in:

SELECT title 
FROM books 
WHERE author_id IN (
    SELECT id FROM authors WHERE last_name ~ '^[A-E]'
);

这显然不同于LEFT-JOIN，你只是想连接表a和表B的东西，即使连接条件在表B中没有找到任何匹配的记录，等等。

如果你只是担心速度，你必须检查你的数据库，写一个好的查询，看看是否有显著的性能差异。

只有当第二个连接表的数据明显多于主表时，才会出现这种差异。我有过这样的经历……

我们有一个用户表，有10万个条目，他们的会员数据(友谊)大约有30万个条目。这是一个join语句，目的是获取好友及其数据，但有很大的延迟。但是当成员表中只有少量数据时，它工作得很好。一旦我们将其更改为使用子查询，它就可以正常工作。

但与此同时，连接查询正在处理比主表拥有更少条目的其他表。

所以我认为连接和子查询语句工作得很好，这取决于数据和情况。

在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。

根据我的观察，就像两种情况，如果一个表的记录少于10万条，那么连接将工作得很快。

但是如果一个表有超过100,000条记录，那么子查询是最好的结果。

我有一个表，其中有500,000条记录，我在查询下面创建了它，它的结果时间是

SELECT * 
FROM crv.workorder_details wd 
inner join  crv.workorder wr on wr.workorder_id = wd.workorder_id;

结果:13.3秒

select * 
from crv.workorder_details 
where workorder_id in (select workorder_id from crv.workorder)

结果:1.65秒