这太模糊了，不能给你一个与你的具体情况相关的答案。这取决于很多因素。Jeff Atwood(这个网站的创始人)确实写过这个。不过，在大多数情况下，如果你有正确的索引，并且正确地执行join，那么执行一次旅行通常比执行几次旅行要快。

构造单独的查询和连接，然后计算每个查询的时间——没有什么比真实的数字更有帮助了。

然后更好的是在每个查询的开头添加“EXPLAIN”。这将告诉您MySQL使用了多少子查询来回答您的数据请求，以及每个查询扫描了多少行。

做了一个快速测试，从50,000行表中选择一行，并连接100,000行表中的一行。基本上是这样的:

$id = mt_rand(1, 50000);
$row = $db->fetchOne("SELECT * FROM table1 WHERE id = " . $id);
$row = $db->fetchOne("SELECT * FROM table2 WHERE other_id = " . $row['other_id']);

vs

$id = mt_rand(1, 50000);
$db->fetchOne("SELECT table1.*, table2.*
    FROM table1
    LEFT JOIN table1.other_id = table2.other_id
    WHERE table1.id = " . $id);

在我的家用慢速电脑上，two select方法读取50,000次需要3.7秒，而JOIN方法需要2.0秒。INNER JOIN和LEFT JOIN没有区别。获取多行(例如，使用IN SET)会产生类似的结果。

根据我的经验，我发现运行几个查询通常更快，特别是在检索大型数据集时。

当与来自另一个应用程序(如PHP)的数据库交互时，到服务器的一次访问要比多次访问多。

还有其他方法可以限制访问服务器的次数，同时仍然运行多个查询，这些方法通常不仅更快，而且使应用程序更易于阅读—例如mysqli_multi_query。

当涉及到SQL时，我不是新手，我认为对于开发人员，尤其是新手来说，有一种趋势是花费大量时间试图编写非常聪明的连接，因为它们看起来很聪明，而实际上有一些聪明的方法来提取数据，看起来很简单。

最后一段是我的个人观点，但我希望这能有所帮助。我同意其他人的观点，尽管他们认为你应该进行基准测试。两种方法都不是灵丹妙药。

真正的问题是:这些记录是一对一的关系还是一对多的关系?

TLDR回答:

如果是一对一，则使用JOIN语句。

如果一对多，则在服务器端代码优化中使用一个(或多个)SELECT语句。

为什么以及如何使用SELECT进行优化

基于一对多关系对大型记录组进行SELECT'ing(使用多个查询而不是连接)可产生最佳效率，因为JOIN'ing存在指数级内存泄漏问题。获取所有数据，然后使用服务器端脚本语言将其分类:

SELECT * FROM Address WHERE Personid IN(1,2,3);

结果:

Address.id : 1            // First person and their address
Address.Personid : 1
Address.City : "Boston"

Address.id : 2            // First person's second address
Address.Personid : 1
Address.City : "New York"

Address.id : 3            // Second person's address
Address.Personid : 2
Address.City : "Barcelona"

在这里，我将在一个select语句中获取所有记录。这比JOIN要好，JOIN每次只获取一小组这样的记录，作为另一个查询的子组件。然后我用服务器端代码解析它，看起来像……

<?php
    foreach($addresses as $address) {
         $persons[$address['Personid']]->Address[] = $address;
    }
?>

何时不使用JOIN进行优化

与多个SELECT语句相比，基于与单个记录的一对一关系连接一大组记录可以产生最佳效率，这些SELECT语句一个接一个地只获得下一个记录类型。

但是JOIN在获取一对多关系的记录时效率很低。

示例:数据库Blogs有3个感兴趣的表，Blogpost、Tag和Comment。

SELECT * from BlogPost
LEFT JOIN Tag ON Tag.BlogPostid = BlogPost.id
LEFT JOIN Comment ON Comment.BlogPostid = BlogPost.id;

如果有1篇博文，2个标签，2条评论，你会得到这样的结果:

Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag2, comment1,
Row4: tag2, comment2,

注意每个记录是如何复制的。2个注释和2个标签等于4行。如果我们有4个注释和4个标签呢?不是8行，而是16行:

Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag1, comment3,
Row4: tag1, comment4,
Row5: tag2, comment1,
Row6: tag2, comment2,
Row7: tag2, comment3,
Row8: tag2, comment4,
Row9: tag3, comment1,
Row10: tag3, comment2,
Row11: tag3, comment3,
Row12: tag3, comment4,
Row13: tag4, comment1,
Row14: tag4, comment2,
Row15: tag4, comment3,
Row16: tag4, comment4,

添加更多的表、更多的记录等，问题将迅速膨胀到数百行，其中大部分都是冗余数据。

这些复制品多少钱?内存(在SQL服务器和试图删除重复项的代码中)和网络资源(在SQL服务器和代码服务器之间)。

来源:https://dev.mysql.com/doc/refman/8.0/en/nested-join-optimization.html;https://dev.mysql.com/doc/workbench/en/wb-relationship-tools.html

根据数据库的复杂性与开发人员的复杂性的不同，执行多次SELECT调用可能更简单。

尝试对JOIN和多个select运行一些数据库统计信息。看看在您的环境中，JOIN是否比SELECT更快/更慢。

然后，如果将其更改为JOIN将意味着额外的一天/一周/一个月的开发工作，我将坚持使用多个select

欢呼,

BLT