与大多数事物数据库一样，答案是取决于情况。
首先，请注意，两种查询模式的结果存在很大差异。
例如，请考虑当table_3为空（不包含任何行）时会发生什么。使用JOIN查询模式，我们将一无所获…结果集将包含零行。
另一个查询对每个表运行单独的查询， 将 返回table_1和中的行table_2。
此外，使用JOIN模式，我们将返回来自table_1，table_2的数据的冗余副本…
但是就“更快”而言，通常JOIN模式会更快，因为它消除了到数据库的许多往返。发送sql，解析令牌，语义检查，制定执行计划，执行计划，准备结果集，将结果集返回给客户端，等待客户端进行提取，然后清理（关闭语句句柄和丢弃结果集。）
当数据库往返次数急剧增加时，每个语句执行的那笔小开销开始大量累积。
好处是，使用简单查询时，要考虑的执行路径数量通常会减少，并且通常在每次查询时都会得到一个合理有效的计划（假设有合适的索引可用）。
JOIN模式的风险在于我们可以生成非常大的集合，其中每一行都包含许多冗余数据。
让我们考虑一个场景：
如果我们在table_1中有1,000行。
如果我们在table_2中有1000行，而table_1中的每一行。
并且如果我们在table_3中有100行针对table_2中的每一行。
如果我们在table_4中有10行，那么table_3中的每一行。
如果我们在table_5中有1行针对table_4中的每一行。
这里有一些快速的数学运算… 10 ^ 3 ^ 10 ^ 3 * 10 ^ 2 * 10 ^ 1 * 10 ^ 0 = 10 ^ 9
这将在结果集中产生十亿行。table_1中每一行的数据将重复10 ^ 6次。那是相同table_1值的一百万个副本。
我们有可能获得“非常大”的结果集，并相应增加资源需求，这可能会导致性能下降。
因此，我们倾向于中间立场。我们更喜欢处理集合，而不是处理RBAR（通过在行上加痛苦来行），但是我们也想避免使用Hugh Jass结果集。
可以在这两种方法之间的某个位置获得最佳性能。例如，通过循环处理来自table_1的各个行，并针对检索到的每一行，我们针对JOIN中的其余四个表运行查询以返回组合结果。
602392714
清零编程群