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

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

我将引用斯坦福大学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.

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

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

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

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

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

这取决于几个因素，包括正在运行的特定查询、数据库中的数据量。子查询首先运行内部查询，然后从结果集中再次过滤出实际结果。而在join中运行并产生结果。

最好的策略是同时测试连接解决方案和子查询解决方案，以获得优化的解决方案。

A general rule is that joins are faster in most cases (99%). The more data tables have, the subqueries are slower. The less data tables have, the subqueries have equivalent speed as joins. The subqueries are simpler, easier to understand, and easier to read. Most of the web and app frameworks and their "ORM"s and "Active record"s generate queries with subqueries, because with subqueries are easier to split responsibility, maintain code, etc. For smaller web sites or apps subqueries are OK, but for larger web sites and apps you will often have to rewrite generated queries to join queries, especial if a query uses many subqueries in the query.

有人说“一些RDBMS可以将子查询重写为连接，或将连接重写为子查询，当它认为其中一个比另一个快时”，但这句话适用于简单的情况，当然不适用于带有子查询的复杂查询，这实际上会导致性能问题。

我不是关系数据库专家，所以对此持保留态度。

子查询与连接的一般思想是较大查询的求值路径。

为了执行较大的查询，必须首先执行每个子查询，然后将结果集存储为与较大查询交互的临时表。

这个临时表没有索引，因此，任何比较都需要扫描整个结果集。

相反，当您使用连接时，所有索引都在使用中，因此，比较需要遍历索引树(或哈希表)，这在速度方面成本要低得多。

现在，我不知道最流行的关系引擎的新版本是否在反向执行求值，只是将必要的元素加载到临时表中，作为优化方法。