查询中有七个内部联接太多了吗？

Question

我有一个有7个内部联接的查询（因为很多信息都分布在其他表中），一些同事感到惊讶。我想知道他们是否应该感到惊讶，或者是否有7个内连接正常？

Answer 1

这并不是闻所未闻，但我会把它放在一个易于使用和维护的视图中

Answer 2

两个问题：

1. 有用吗？
2. 你能解释一下吗？

如果是这样，那么七就没事了。如果你无法解释查询，那么七就太多了。

Answer 3

如果您的架构位于5th normal form：）

，这是正常的

Answer 4

根据您要完成的操作，查询中的大量连接并不显着。

就个人而言，我不太关心用于返回所需结果集的连接数，而是更关心查询是否已经优化并在可接受的参数范围内运行。

如果查询已完全优化且无法修剪但查询本身执行速度不够快，那么数据结构设计可能与您尝试执行的操作不匹配。此时，您可以重新评估您要完成的工作或为您的业务模式提供数据的结构。

Answer 5

这并不奇怪。使用像Siebel这样的系统，通常会看到连接计数为两位数。

Answer 6

七个连接使得可读性变得更加困难，但更重要的是性能和可伸缩性。如果这些都没问题，那就去吧。

Answer 7

这可能不正常，但肯定不会过分。如果您发现自己一遍又一遍地加入相同的表格，请创建一些视图。

Answer 8

连接数取决于您的数据模型，如果您查询的是7个连接可以在您的查询中 - 我记得在我很久以前工作的应用程序中有类似的查询，性能取决于许多因素（表大小，索引，服务器负载，服务器配置名称很少）我不认为它可以推广7连接是坏的。

如果它适合你，那我觉得很好：D

Answer 9

是的，这是正常的 - 但是，从表现的角度来看，它确实不是一个好主意。由于查询计划是基于估计的成本构建的，因此当您增加联接（或任何其他运算符）时会有increase in the number of errors：

  

SQL Server查询优化器将估计来自搜索运算符的最少一行。这样做是为了避免由于基数低估而选择非常昂贵的子树的情况。如果估计子树返回零行，则许多计划的成本大致相同，因此计划选择中可能存在错误。因此，您会注意到此情况下的估计值“高”，并且可能会导致一些错误。您还可能会注意到我们估计该分支的20次执行而不是实际的10次。但是，考虑到在此运算符之前已经计算的连接数，因此不被认为是2（10行）的关闭太糟糕了。 （错误可以随着联接数量呈指数增长）。

此外，优化程序会尝试平衡计划制定所需的时间与潜在的节省 - 它不会花费一整天时间来寻找最佳计划。连接越多，替代计划的数量就越多 - 其中一些可能比优化器有时间找到的更优化。

Answer 10

在数据仓库中，7或甚至更多并不常见，因为事实表可以很容易地拥有十几个维度的外键。在数据仓库场景中，与事实表相比，维度的基数通常较低，因此维度上的过滤器有助于通过索引搜索或扫描来利用事实表。

对于规范化的事务模式，如果主基表中结果集的基数较低（即选择关于一个客户的所有内容），通常不会出现问题，因为外键通常只能导致索引搜索或索引扫描。

Answer 11

如果数据库设计需要，

7就可以了。但是，如果7是实现目标所必需的，我会重新检查数据库设计，以确保这种隐蔽性确实是必要的。

出于好奇，这是DB2吗？只是我注意到的一种模式：）

Answer 12

是同一个表上的7个内部联接，不同表上的7个内部联接，还是7个嵌套内部联接？

......技巧问题！这无关紧要，如果这是您的数据库结构所需要的，那么它是正确的

警告：如果它是同一个表上的7个嵌套内连接，那么你可能有一个结构不合理的表; - ）

Answer 13

我认为你要避免的是一个大于7的连接深度.7个深度小于7个连接的内连接肯定不是闻所未闻，但有时人们会听到“7连接”并认为禁止是7个连接，而不是深度。

Answer 14

这当然不常见。但是至少在Oracle中，7是一个特殊数字，不止于此，优化器不能再测试每个连接顺序（由于可能性的因子增长）。因此，除非你准备照看你的执行计划，否则避免超过7是明智的。