【发布时间】：2010-09-20 06:03:12
【问题描述】：
我有一个有 7 个内部联接的查询（因为很多信息分布在其他表中），一些同事感到很惊讶。我想知道他们是否应该感到惊讶还是有 7 个内部连接正常？
【问题讨论】：
标签： sql inner-join
【发布时间】：2010-09-20 06:03:12
【问题描述】：
这并非闻所未闻，但为了便于使用和维护，我会将其放在视图中
【讨论】：
-
我非常喜欢规范化数据库，但有时我会说“我需要一个视图。现在。”然后去做一个。
-
视图需要与存储的过程一起消失。触发器可以保留。
-
@Shawn：虚拟关系变量（“视图”）有助于数据独立性。 DBMS 中很少有比这更有用的功能了。
-
@Shawn：嗯，这当然是一种反传统观点。让我们从你开始吧。我会最后一个。 :D 你搞错了。
两个问题：
- 有效吗？
- 你能解释一下吗？
如果是这样，那么七就可以了。如果您无法解释查询，那么七个太多了。
【讨论】：
如果您的架构在5th normal form 中，这很正常：)
【讨论】：
根据您要完成的任务，查询中的大量连接并不显着。
就我个人而言，我不太关心用于返回所需结果集的连接数量，而更关心查询是否经过优化并在可接受的参数范围内运行。
如果查询已完全优化且无法缩减，但查询本身执行速度不够快，则数据结构设计可能不适合您尝试执行的操作。此时，您可以重新评估您要完成的工作或为您的业务模型提供数据的结构。
【讨论】：
这一点也不稀奇。对于像 Siebel 这样的系统，连接计数通常会出现两位数。
【讨论】：
七连接使可读性更加困难，但更重要的是性能和可扩展性。如果这些都可以，那就去吧。
【讨论】：
这可能不正常，但肯定不会过度。如果您发现自己一遍又一遍地加入同一个表，请创建一些视图。
【讨论】：
连接数取决于您的数据模型，如果您查询的是 7 个连接，那么您的查询中可以有 7 个连接 - 我记得在我很久以前工作过的应用程序中有类似的查询，性能取决于许多因素（表大小、索引、服务器负载、服务器配置等等），我认为不能一概而论地认为 7 个连接是不好的。
如果它适合你，那么我想它很好：D
【讨论】：
是的，这很正常 - 但实际上，从性能的角度来看，这并不是一个好主意。由于查询计划是基于估计成本构建的，因此当您增加连接（或任何其他运算符，就此而言）时，会有一个increase in the number of errors：
SQL Server 查询优化器将估计至少一行来自查找运算符。这样做是为了避免由于基数低估而选择非常昂贵的子树的情况。如果估计子树返回零行，则许多计划的成本大致相同，因此计划选择可能会出现错误。因此，您会注意到这种情况下的估计值“很高”，并且可能会导致一些错误。您可能还注意到，我们估计此分支执行了 20 次，而不是实际的 10 次。但是，考虑到在此运算符之前已评估的连接数，不考虑偏离 2 倍（10 行）太糟糕了。 （错误会随着连接的数量呈指数增长）。
此外，优化器会尝试平衡制定计划所需的时间与可能节省的时间 - 它不会整天都在寻找最佳计划。连接越多，存在的替代计划的数量就越多 - 其中一些可能比优化器有时间找到的更优化。
【讨论】：
7 甚至更多在数据仓库中一点也不稀奇，因为事实表很容易拥有十几个维度的外键。在数据仓库场景中，维度的基数通常低于事实表，因此维度上的过滤器有助于通过索引查找或扫描来利用事实表。
对于规范化事务模式，如果结果集的基数在主基表中较低（即选择关于一个客户的所有内容）通常不是问题，因为外键通常可以简单地导致索引查找或索引扫描。
【讨论】：
如果您的数据库设计需要，7 很好。但是，如果 7 是实现您的目标所必需的，我会重新检查数据库设计以确保确实需要这种程度的模糊性。
出于好奇，这是 DB2 吗？只是我注意到的一种模式:)
【讨论】：
这是同一张表上的 7 个内连接，不同表上的 7 个内连接，还是 7 个 嵌套 内连接？
...技巧问题！没关系，如果你的数据库结构是这样的，那就对了
警告：如果在同一张表上有 7 个嵌套的内连接，则您的表可能结构不佳；-)
【讨论】：
这当然不是不寻常的。然而，至少在 Oracle 中，7 是一个特殊的数字，因为超过这个数字，优化器就不能再测试每个连接顺序（由于可能性数量的阶乘增长）。因此，除非您准备好照看执行计划，否则最好避免超过 7 个。
【讨论】：
我认为您要避免的是大于 7 的连接深度。深度小于 7 的连接的 7 个内部连接当然不是闻所未闻，但有时人们听到“7 连接”并认为禁忌是7 个连接，而不是深度。
【讨论】：
-
“深度”是什么意思？我认为它是并行连接，而不是串行连接。