关于sql：Join与子查询

Join vs. sub-query

我是一个老门派的MySQL用户，总是喜欢使用JOIN而不是子查询。但是现在每个人都使用子查询，我讨厌它；我不知道为什么。

如果有什么不同，我缺乏自己判断的理论知识。子查询是否与JOIN一样好，因此没有什么可担心的？

相关讨论

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

但实际上，答案通常归结于表演。有些乐观主义者在给出一个连接与子查询时会吸吮柠檬，而有些乐观主义者则相反，这是乐观主义者特有的、DBMS版本特有的和查询特有的。

从历史上看，显式连接通常是成功的，因此已经确立的连接更好的智慧，但是乐观主义者一直都在变得更好，所以我更喜欢先以逻辑一致的方式编写查询，然后在性能约束允许的情况下重新构造查询。

相关讨论

很好的回答。我还要补充一点，开发人员(特别是业余人员)并不总是精通SQL。
+1.在快速前进之前，先把它弄好。
+我一直在寻找这个问题的逻辑解释，这是我认为唯一合乎逻辑的答案。
@马塞洛·坎托斯，你能举一个例子说明一下你的说法吗："从实际意义上讲，这也是更安全的，因为你不必担心由于与B的多次比赛而从A中得到重复的事实。"我觉得这很有洞察力，但有点抽象。谢谢。
@购买贵重物品的精汇牛客户：select custid from cust join bought using (custid) where price > 500。如果一个顾客买了多件贵重物品，你会得到双倍的补偿。为了解决这个问题，select custid from cust where exists (select * from bought where custid = cust.custid and price > 500)。您可以使用select distinct …来代替，但它通常对优化器或评估器来说要做更多的工作。
不过，您甚至需要在示例中进行连接吗？SELECT custid FROM bought WHERE price > 500不够吗？对不起，如果这看起来有点学究，但是你的例子让我有点困惑。
@是的，我用了一个过于简单的答案，因为我很懒。在一个真实的场景中，您将从CUST中提取更多的列，而不仅仅是CUSTID。
为机器编写代码与为人类编写代码之间的永恒困境。有些人会争辩说，在问题出现之前不要担心性能，我会补充说：测试测试测试连接比子查询快得多的声明
@用户10089632同意这一点，但这只是历史上的一个两难问题，因为SQL引擎在优化方面受挫。这并不完全是作者的错，因为SQL语义使得重写表达式比在适当的关系引擎中要困难得多。现代的SQL引擎在这方面要好得多，但要达到这一点，这是一条漫长的道路，而且还有很长的路要走，IMO。
我以前犯过这个错误，我认识的一些人一直在犯这个错误：选择sum(a.something)作为sumsomething，…从b.a_id=a.id上的左边join b开始，所以是的，子查询对于非超级专业人员更安全。

在大多数情况下，JOIN比子查询更快，而且子查询更快是非常罕见的。

在JOIN中，RDBMS可以创建一个更适合查询的执行计划，可以预测应该加载哪些数据以进行处理并节省时间，而不像子查询那样，它将运行所有查询并加载所有数据以进行处理。

子查询的好处在于，它们比JOIN的可读性更强：这就是大多数新的SQL人员更喜欢它们的原因；这是一种简单的方法；但在性能方面，连接在大多数情况下都更好，即使它们也不难读取。

相关讨论

是的，因此大多数数据库都将它作为优化步骤，在分析查询时将子查询转换为联接。
这个答案对于被问到的问题来说过于简单了。如您所述：某些子查询正常，而某些子查询不正常。答案并不能真正帮助区分这两者。(另外，"非常罕见"还取决于您的数据/应用程序)。
@Kronass你是完全正确的，不过，我认为连接在格式良好时更容易阅读。
你能用文档参考或测试结果证明你的观点吗？
我在包含对上查询的后引用的子查询方面有很好的经验，特别是当行数超过100000时。似乎是内存使用和交换文件的分页。一个连接将产生大量的数据，这些数据可能不适合内存，必须分页到交换文件中。在这种情况下，像select * from a where a.x = (select b.x form b where b.id = a.id)这样的小子选择的查询时间与联接相比非常小。这是一个非常具体的问题，但在某些情况下，它会把你从几个小时带到几分钟。
我对Oracle很有经验，我可以说，如果没有任何筛选或排序，那么子查询在大型表上会更好。
我在sqlserver方面也有类似的经验。子查询通常要快得多。
我已经读到mysql专门处理嵌套子查询不好。Postgres显然更好。
有人告诉我，我更喜欢连接，而不是SQL Server的优化，因为SQL Server架构师花费大量时间在优化连接的方法上。然而，在实践中，我发现这种方法常常产生可怕的结果，而且，依我看，这是一种放弃责任的做法。加入有自己的特殊危险和风险，这些危险和风险往往被忽视(直到现实被咬伤)。每种方法都有优点和缺点；实验、测量和经验将最终成为任何给定情况下的最佳指南。
这个答案是8年前写的。这在今天(截至2018年3月1日)仍然是真的吗？
@哪一个DBMS可以做这样的优化？
@Tuxayo检查特定查询的查询计划，查看数据库是否进行了正确的优化。它取决于更多的因素，而不仅仅是支持它的DBMS，如其他一些答案所述。

摘自mysql手册(13.2.10.11将子查询重写为join)：

A LEFT [OUTER] JOIN can be faster than an equivalent subquery because the server might be able to optimize it better—a fact that is not specific to MySQL Server alone.

号

所以子查询可能比LEFT [OUTER] JOIN慢，但在我看来，它们的强度稍微高一些。

相关讨论

使用explain查看数据库如何对数据执行查询。在这个答案中有一个巨大的"它取决于"…

PostgreSQL可以将子查询重写为join或join-to-subquery，前提是它认为一个比另一个快。这一切都取决于数据、索引、相关性、数据量、查询等。

相关讨论

首先，要比较这两个查询，首先应将查询与子查询区分为：

一类子查询，始终使用联接编写相应的等效查询。

无法使用联接重写的子查询类

对于第一类查询，一个好的RDBMS将把联接和子查询视为等价的，并将生成相同的查询计划。

现在连MySQL都这样做了。

尽管如此，有时也不会，但这并不意味着连接总是会赢——我在MySQL中使用子查询时遇到过一些情况，这提高了性能。(例如，如果有什么东西阻碍了MySQL Planner正确估计成本，并且计划器没有看到连接变量和子查询变量相同，那么子查询可以通过强制某个路径来优于连接)。

结论是，如果您想确定哪一个查询的性能更好，那么应该同时测试您的查询的联接和子查询变体。

对于第二个类，比较没有意义，因为这些查询不能使用联接重写，在这些情况下，子查询是完成所需任务的自然方式，您不应该歧视它们。

相关讨论

在2010年，我将加入这个问题的作者，并将强烈投票支持JOIN。但是有了更多的经验(尤其是在MySQL中)，我可以声明：是的，子查询可以更好。我在这里读了很多答案。有人说，子查询速度更快，但缺乏很好的解释。我希望我能提供这个(非常)迟的答案：

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

第二个重要声明：规模至关重要

如果使用子查询，您应该知道DB服务器是如何执行子查询的。特别是如果子查询被计算一次或每行一次！另一方面，现代数据库服务器能够进行大量优化。在某些情况下，子查询有助于优化查询，但更新版本的DB服务器可能会使优化过时。

选择字段中的子查询

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

请注意，对于来自foo的每个结果行执行子查询。如果可能的话，避免这种情况，它可能会大大降低对大型数据集的查询速度。但如果子查询没有引用foo的话，数据库服务器可以将其作为静态内容进行优化，并且只能进行一次评估。

WHERE语句中的子查询

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

号

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

join语句中的子查询

1
2
3
4
5

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

这很有趣。我们将JOIN与子查询相结合。这里我们得到了子查询的真正优势。设想一个数据集，在wilco中有数百万行，但只有几个不同的me。我们现在有了一个较小的临时表，而不是针对一个大表进行联接。这可能导致更快的查询，具体取决于数据库的大小。您可以对CREATE TEMPORARY TABLE ...和INSERT INTO ... SELECT ...具有相同的效果，这可能在非常复杂的查询上提供更好的可读性(但可以将数据集锁定在可重复的读取隔离级别)。

嵌套子查询

1
2
3
4
5
6
7
8
9

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

。

可以在多个级别中嵌套子查询。如果必须对结果进行分组或排序，这可以帮助处理大型数据集。通常，DB服务器为此创建一个临时表，但有时您不需要对整个表进行排序，只需要对结果集进行排序。根据表的大小，这可能提供更好的性能。

结论

子查询不能代替JOIN，您不应该这样使用它们(尽管可能)。在我看来，正确使用子查询是用来快速替换CREATE TEMPORARY TABLE ...。一个好的子查询在某种程度上减少了一个数据集，你不能在一个JOIN的ON语句中完成。如果子查询有一个关键字GROUP BY或DISTINCT并且最好不位于select字段或where语句中，那么它可能会大大提高性能。

相关讨论

对于Sub-queries in the Join-statement：(1)从子查询本身生成派生表可能需要很长时间。(2)生成的派生表没有索引。这两个单独使用可以显著降低SQL的速度。
@jxc我只能代表mysql(1)那里有一个类似join的临时表。时间取决于数据量。如果无法使用子查询减少数据，请使用联接。(2)这是正确的，这取决于您可以减少临时表中数据的因素。我有一些实际情况，我可以将连接大小从数百万减少到几百，并通过子查询将查询时间从几秒(使用完整索引)减少到四分之一秒。
IMO：(1)这种临时表(派生表)没有具体化，因此每次运行SQL时，都必须重新创建临时表，这可能会非常昂贵，而且是真正的瓶颈(即在数百万条记录上运行一个分组)(2)即使您可以将临时表的大小减少到10条记录，因为没有索引，仍然是M。EAN在联接其他表时，查询的数据记录可能比不查询临时表多9倍。顺便说一句，在我的数据库(mysql)中，我以前遇到过这个问题，在SELECT list中使用子查询可能要快得多。
@JXC我不怀疑有很多例子，其中使用子查询是不太理想的。作为良好的实践，在优化之前，您应该在查询上使用EXPLAIN。使用旧的set profiling=1，您可以很容易地看到临时表是否是一个瓶颈。甚至一个索引也需要处理时间，B-树优化了对记录的查询，但是一个10记录表比一个索引可以快得多。但它取决于多种因素，如字段大小和类型。
使用EXPLAIN应该足够了解派生表(从"从"列表中的子查询创建)如何影响查询。我在工作中经常使用子查询，只是尽量提到Sub-queries in the Join-statement可能没有你想象的那么有前途。临时表中减少的记录的成本可能比其收益大得多。还要记住，即使最后的连接可能花费更少的时间，扫描子查询中数百万条记录的时间仍然存在，并且需要为每个SQL运行计数。
@JXC可能在我们进行查询的不同领域产生了不同的体验。join语句中的子查询当然是有前途的，但可能我错过了真正的键约束，这对于获得巨大的性能增益是必不可少的。也许像MIN()这样的聚合函数是导致略有不同的连接策略的转折点，尽管我已经声明聚合是使用子查询的关键因素。

SQL Server的msdn文档显示

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.

号

所以如果你需要类似的东西

1	SELECT * FROM t1 WHERE EXISTS SELECT * FROM t2 WHERE t2.parent=t1.id

。

尝试改用join。在其他情况下，这没有区别。

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

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

相关讨论

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

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

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

学生桌

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

+------+--------+------+--------+
| 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 |
+------+--------+------+--------+

应用表格

(针对特定大学和专业的申请)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

+------+----------+----------------+----------+
| 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 |
+------+----------+----------------+----------+

号

让我们试着找出申请过CS专业(不考虑大学)的学生的GPA分数。

使用子查询：

1
2
3
4
5
6
7
8
9
10
11

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 |
+------+

此结果集的平均值为：

1
2
3
4
5
6
7

SELECT avg(GPA) FROM Student WHERE sID IN (SELECT sID FROM Apply WHERE major = 'CS');

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

。

使用联接：

1
2
3
4
5
6
7
8
9
10
11
12
13

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 |
+------+

此结果集的平均值：

1
2
3
4
5
6
7

SELECT avg(GPA) FROM Student, Apply WHERE Student.sID = Apply.sID AND Apply.major = 'CS';

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

。

很明显，第二次尝试会在我们的用例中产生误导性的结果，因为在计算平均值时，它会计算重复项。很明显，在基于连接的语句中使用distinct并不能消除这个问题，因为它会错误地将3.9分数的三分之一保留下来。正确的情况是，假设我们有两(2)名学生的分数符合我们的查询条件，那么我们就要考虑两(2)次出现的3.9分。

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

相关讨论

从一个老的mambo cms运行在一个非常大的数据库上：

1
2
3
4
5
6
7
8
9

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

0秒

1
2
3
4
5
6
7

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

号

~3秒

一个解释表明，他们检查的行数完全相同，但一个需要3秒，一个接近于瞬间。故事的寓意？如果绩效很重要(不是什么时候？)，尝试多种方法，看看哪种方法最快。

还有…

1
2
3
4
5
6
7

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

0秒

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

相关讨论

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

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

请注意，对子查询的结果使用普通值运算符只需要返回一个字段。如果您有兴趣检查一组其他值中是否存在单个值，请使用：

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

号

这显然不同于左联接，即您只想联接表A和B中的内容，即使联接条件在表B中找不到任何匹配的记录，等等。

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

根据我的观察，就像两个例子，如果一个表的记录少于100000条，那么连接将很快工作。

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

我在下面的查询中创建了一个有500000条记录的表，其结果时间如下

1
2
3

SELECT *
FROM crv.workorder_details wd
INNER JOIN crv.workorder wr ON wr.workorder_id = wd.workorder_id;

。

Result : 13.3 Seconds

号

1
2
3

SELECT *
FROM crv.workorder_details
WHERE workorder_id IN (SELECT workorder_id FROM crv.workorder)

Result : 1.65 Seconds

号

相关讨论

mysql版本：5.5.28-0ubuntu0.12.04.2-log

我也觉得join总是比mysql中的子查询好，但是explain是一种更好的判断方法。下面是一个例子，其中子查询比联接工作得更好。

以下是我的3个子查询：

1
2
3
4
5
6
7
8
9
10

EXPLAIN SELECT vrl.list_id,vrl.ontology_id,vrl.position,l.name AS list_name, vrlih.position AS previous_position, vrl.moved_date
FROM `vote-ranked-listory` vrl
INNER JOIN lists l ON l.list_id = vrl.list_id
INNER JOIN `vote-ranked-list-item-history` vrlih ON vrl.list_id = vrlih.list_id AND vrl.ontology_id=vrlih.ontology_id AND vrlih.type='PREVIOUS_POSITION'
INNER JOIN list_burial_state lbs ON lbs.list_id = vrl.list_id AND lbs.burial_score < 0.5
WHERE vrl.position <= 15 AND l.status='ACTIVE' AND l.is_public=1 AND vrl.ontology_id < 1000000000
AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=43) IS NULL
AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=55) IS NULL
AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=246403) IS NOT NULL
ORDER BY vrl.moved_date DESC LIMIT 200;

解释显示：

1
2
3
4
5
6
7
8
9
10
11

。

使用join的相同查询是：

1
2
3
4
5
6
7
8
9
10
11

EXPLAIN SELECT vrl.list_id,vrl.ontology_id,vrl.position,l.name AS list_name, vrlih.position AS previous_position, vrl.moved_date
FROM `vote-ranked-listory` vrl
INNER JOIN lists l ON l.list_id = vrl.list_id
INNER JOIN `vote-ranked-list-item-history` vrlih ON vrl.list_id = vrlih.list_id AND vrl.ontology_id=vrlih.ontology_id AND vrlih.type='PREVIOUS_POSITION'
INNER JOIN list_burial_state lbs ON lbs.list_id = vrl.list_id AND lbs.burial_score < 0.5
LEFT JOIN list_tag lt1 ON lt1.list_id = vrl.list_id AND lt1.tag_id = 43
LEFT JOIN list_tag lt2 ON lt2.list_id = vrl.list_id AND lt2.tag_id = 55
INNER JOIN list_tag lt3 ON lt3.list_id = vrl.list_id AND lt3.tag_id = 246403
WHERE vrl.position <= 15 AND l.status='ACTIVE' AND l.is_public=1 AND vrl.ontology_id < 1000000000
AND lt1.list_id IS NULL AND lt2.tag_id IS NULL
ORDER BY vrl.moved_date DESC LIMIT 200;

。

输出为：

1
2
3
4
5
6
7
8
9
10
11

+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+
| id | select_type | TABLE | TYPE | possible_keys | KEY | key_len | REF | ROWS | Extra |
+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+
| 1 | SIMPLE | lt3 | REF | list_tag_key,list_id,tag_id | tag_id | 5 | const | 2386 | USING WHERE; USING TEMPORARY; USING filesort |
| 1 | SIMPLE | l | eq_ref | PRIMARY,STATUS,ispublic,idx_lookup,is_public_status | PRIMARY | 4 | ranker.lt3.list_id | 1 | USING WHERE |
| 1 | SIMPLE | vrlih | REF | PRIMARY | PRIMARY | 4 | ranker.lt3.list_id | 103 | USING WHERE |
| 1 | SIMPLE | vrl | REF | PRIMARY | PRIMARY | 8 | ranker.lt3.list_id,ranker.vrlih.ontology_id | 65 | USING WHERE |
| 1 | SIMPLE | lt1 | REF | list_tag_key,list_id,tag_id | list_tag_key | 9 | ranker.lt3.list_id,const | 1 | USING WHERE; USING INDEX; NOT EXISTS |
| 1 | SIMPLE | lbs | eq_ref | PRIMARY,idx_list_burial_state,burial_score | PRIMARY | 4 | ranker.vrl.list_id | 1 | USING WHERE |
| 1 | SIMPLE | lt2 | REF | list_tag_key,list_id,tag_id | list_tag_key | 9 | ranker.lt3.list_id,const | 1 | USING WHERE; USING INDEX |
+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+

通过比较rows列可以看出不同之处，而带有连接的查询使用Using temporary; Using filesort。

当然，当我同时运行这两个查询时，第一个查询是在0.02秒内完成的，第二个查询即使在1分钟后也不会完成，所以请解释清楚这些查询。

如果我在list_tag表上没有内部连接，即如果我删除

1	AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=246403) IS NOT NULL

。

从第一个查询开始，相应地：

1	INNER JOIN list_tag lt3 ON lt3.list_id = vrl.list_id AND lt3.tag_id = 246403

在第二个查询中，explain为两个查询返回相同数量的行，并且这两个查询的运行速度相同。

相关讨论

子查询能够即时计算聚合函数。例如，找到该书的最低价格，并获取以该价格出售的所有书籍。1)使用子查询：

1
2
3
4
5

SELECT titles, price
FROM Books, Orders
WHERE price =
(SELECT MIN(price)
FROM Orders) AND (Books.ID=Orders.ID);

。

2)使用连接

1
2
3
4
5
6
7
8
9
10

SELECT MIN(price)
FROM Orders;
-----------------
2.99

SELECT titles, price
FROM Books b
INNER JOIN Orders o
ON b.ID = o.ID
WHERE o.price = 2.99;

号

相关讨论

一般来说，连接在大多数情况下更快(99%)。
数据表越多，子查询就越慢。
数据表的数量越少，子查询的速度与联接速度相同。
子查询更简单、更易于理解和阅读。
大多数web和app框架及其"orm"和"active record"使用子查询生成查询，因为使用子查询更容易划分责任、维护代码等。
对于较小的网站或应用程序，子查询是可以的，但是对于较大的网站和应用程序，您通常需要重写生成的查询来联接查询，特别是如果查询中使用了许多子查询。

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

相关讨论

只有当第二个联接表的数据明显多于主表时，才会看到这种差异。我有过如下的经历…

我们有一个用户表，有10万个条目，他们的成员数据(友谊)大约有30万个条目。这是一个连接语句，用来接收朋友和他们的数据，但是有很大的延迟。但在成员表中只有少量数据的情况下，它工作得很好。一旦我们将其更改为使用子查询，它就工作得很好。

但同时，联接查询正在处理的其他表的条目数比主表少。

所以我认为join和sub-query语句工作得很好，这取决于数据和情况。

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

我只是在想同样的问题，但是我在from部分使用了子查询。我需要从大表进行连接和查询，"从"表有2800万条记录，但结果只有128条那么小的结果大数据！我正在对它使用max()函数。

首先，我使用左连接，因为我认为这是正确的方法，MySQL可以优化等等。第二次只是为了测试，我重写以针对连接进行子选择。

左连接运行时：1.12s子选择运行时间：0.06s

比加入快18倍！就在"乔基托"副词中，副词看起来很糟糕，但结果…

如果要使用join加快查询速度：

对于"内部联接/联接"，不要使用Where条件，而是在"on"条件下使用它。如：

1
2
3
4
5
6
7
8

SELECT id,name FROM table1 a
JOIN table2 b ON a.name=b.name
WHERE id='123'

Try,

SELECT id,name FROM table1 a
JOIN table2 b ON a.name=b.name AND a.id='123'

对于"左/右连接"，不要在"on"条件下使用，因为如果使用左/右联接，它将获取任何一个表的所有行。因此，在"on"中不使用它。所以，尝试使用"Where"条件