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

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

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

欢呼,

BLT

对于内部连接，单个查询是有意义的，因为您只获得匹配的行。 对于左连接，多个查询要好得多……看看下面我做的基准测试:

5个join的单个查询 查询:8.074508秒 结果大小:2268000 一行5个查询 组合查询时间:0.00262秒 结果大小:165 (6 + 50 + 7 + 12 + 90)

.

注意，我们在这两种情况下得到了相同的结果(6 x 50 x 7 x 12 x 90 = 2268000)

左连接使用指数级的冗余数据内存。

如果只连接两个表，内存限制可能没有那么糟糕，但通常是三个或三个以上，因此值得进行不同的查询。

顺便说一句，我的MySQL服务器就在我的应用服务器旁边…所以连接时间可以忽略不计。如果您的连接时间以秒为单位，那么可能会有好处

弗兰克

就吞吐量而言，它会更快吗?可能。但它也可能一次锁定更多的数据库对象(取决于您的数据库和模式)，从而降低并发性。根据我的经验，人们经常被“更少的数据库往返”的说法所误导，而在现实中，在大多数OLTP系统中，数据库位于同一个LAN上，真正的瓶颈很少是网络。

是否应该使用连接首先是关于连接是否有意义。只有在这种情况下，性能才会被考虑，因为几乎所有其他情况都会导致明显更差的性能。

性能差异很大程度上取决于所查询信息的相关性。联接是有用的，当数据相关且索引正确时，联接速度很快，但它们通常会导致一些冗余，有时结果比需要的多。如果您的数据集不是直接相关的，那么将它们放在一个查询中将导致所谓的笛卡尔积(基本上是所有可能的行组合)，这几乎不是您想要的结果。

这通常是由多对一对多关系引起的。例如，HoldOffHunger的回答提到了一个关于帖子、标签和评论的查询。评论与一篇文章相关，标签也是如此。但是标签与注释无关。

+------------+     +---------+     +---------+
|  comment   |     |   post  |     |  tag    |
|------------|*   1|---------|1   *|---------|
| post_id    |-----| post_id |-----| post_id |
| comment_id |     | ...     |     | tag_id  |
| user_id    |     |         |     | ...     |
| ...        |     |         |     | ...     |
+------------+     +---------+     +---------+

在这种情况下，最好至少有两个独立的查询。如果您试图连接标记和注释，因为两者之间没有直接的关系，您最终会得到标记和注释的所有可能组合。许多*许多=许多许多。除此之外，由于帖子和标签是不相关的，您可以并行执行这两个查询，从而获得潜在的收益。

让我们考虑一个不同的场景:您希望将评论附加到一篇文章，以及评论者的联系信息。

 +----------+     +------------+     +---------+
 |   user   |     |  comment   |     |   post  |
 |----------|1   *|------------|*   1|---------|
 | user_id  |-----| post_id    |-----| post_id |
 | username |     | user_id    |     | ...     |
 | ...      |     | ...        |     +---------+
 +----------+     +------------+

This is where you should consider a join. Aside from being a much more natural query, most database systems (including MySQL) have lots of smart people put lots of hard work into optimizing queries just like it. For separate queries, since each query depends on the results of the previous one, the queries can't be done in parallel, and the total time becomes not just the actual execute time of the queries, but also the time spent fetching results, sifting through them for IDs for the next query, linking rows together, etc.

做了一个快速测试，从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)会产生类似的结果。

有几个因素，这意味着没有二元答案。什么对性能最好取决于您的环境。顺便说一下，如果带有标识符的单个选择不是次秒级的，那么您的配置可能有问题。

真正要问的问题是您希望如何访问数据。单个选择支持后期绑定。例如，如果您只想要员工信息，您可以从Employees表中进行选择。外键关系可用于在以后根据需要检索相关资源。选择已经有一个键指向，所以它们应该非常快，你只需要检索你需要的。必须始终考虑到网络延迟。

联接将一次检索所有数据。如果您正在生成一个报告或填充一个网格，这可能正是您想要的。在这种情况下，编译和优化的连接将比单一选择更快。请记住，Ad-hoc连接可能没有那么快——您应该将它们编译(到存储的proc中)。速度取决于执行计划，该计划详细说明了DBMS检索数据所采取的步骤。