JOIN查询是否比多个查询快?(运行主查询,然后根据主查询的结果运行许多其他select)

我这么问是因为加入它们会使我的应用程序的设计复杂化

如果它们快了,有人能大致估计出快了多少吗?如果是1.5倍,我不在乎,但如果是10倍,我就在乎。


当前回答

做了一个快速测试,从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时,我不是新手,我认为对于开发人员,尤其是新手来说,有一种趋势是花费大量时间试图编写非常聪明的连接,因为它们看起来很聪明,而实际上有一些聪明的方法来提取数据,看起来很简单。

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

这里有100个有用的查询链接,这些都是在Oracle数据库中测试的,但记住SQL是标准的,Oracle, MS SQL Server, MySQL和其他数据库之间的区别是SQL方言:

http://javaforlearn.com/100-sql-queries-learn/

这个问题很老了,但是缺少一些基准。我对比了JOIN的两个竞争对手:

N + 1查询 2个查询,第二个查询使用WHERE IN(…)或等价的

结果很明显:在MySQL上,JOIN要快得多。N+1个查询会大大降低应用程序的性能:

也就是说,除非您选择了大量指向极少数不同的外部记录的记录。下面是极端情况下的基准测试:

在典型的应用程序中,这种情况不太可能发生,除非您正在连接一对多的关系,在这种情况下,外键在另一个表上,并且您多次复制主表数据。

导读:

对于*对1关系,总是使用JOIN 对于*对多的关系,第二个查询可能更快

更多信息请参阅我在Medium上的文章。

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

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

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

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

这通常是由多对一对多关系引起的。例如,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.