我有一个有 7 个内部联接的查询（因为很多信息分布在其他表中），一些同事感到惊讶。我想知道他们是否应该感到惊讶还是有 7 个内部连接正常？
isc_fausto
问问题
7596 次
14 回答
25
这并非闻所未闻，但为了便于使用和维护，我会将其置于视图中
于 2008-10-31T19:04:07.607 回答
17
两个问题：
- 它有效吗？
- 你能解释一下吗？
如果是这样，那么七就可以了。如果您无法解释查询，那么七个太多了。
于 2008-10-31T19:04:31.163 回答
5
如果您的架构是第5 范式，这很正常：)
于 2008-10-31T19:03:41.227 回答
4
根据您要完成的任务，查询中的大量连接并不显着。
就个人而言，我不太关心用于返回所需结果集的连接数量，而更关心查询是否经过优化并在可接受的参数范围内运行。
如果查询已完全优化并且无法缩减，但查询本身执行速度不够快，则数据结构设计可能不适合您尝试执行的操作。此时，您可以重新评估您要完成的工作或为您的业务模型提供数据的结构。
于 2008-10-31T19:05:51.643 回答
3
这一点也不稀奇。对于像 Siebel 这样的系统，通常会看到两位数的连接计数。
于 2008-10-31T19:06:15.717 回答
3
七个连接使得可读性更难，但更重要的是性能和可伸缩性。如果这些都可以，那就去吧。
于 2008-10-31T19:06:15.747 回答
2
这可能不正常，但肯定不会过度。如果您发现自己一遍又一遍地加入相同的表，请创建一些视图。
于 2008-10-31T19:05:59.833 回答
2
连接的数量取决于您的数据模型，如果您查询的是 7 个连接，则可以在您的查询中 - 我记得在我很久以前工作的应用程序中有类似的查询，性能取决于许多因素（表大小，索引，服务器负载，服务器配置等等），我认为不能一概而论地认为 7 个连接是不好的。
如果它对你有用，那么我想它很好：D
于 2008-10-31T19:06:39.490 回答
2
是的，这很正常——但实际上，从性能的角度来看，这并不是一个好主意。由于查询计划是建立在估计成本之上的，因此当您增加连接（或任何其他运算符，就此而言）时，错误数量会增加：
SQL Server 查询优化器将估计至少一行来自查找运算符。这样做是为了避免由于基数低估而选择非常昂贵的子树的情况。如果估计子树返回零行，许多计划的成本大致相同，因此计划选择可能会出现错误。因此，您会注意到这种情况下的估计值“很高”，并且可能会导致一些错误。您可能还注意到，我们估计此分支执行了 20 次，而不是实际的 10 次。但是，考虑到在此运算符之前已评估的连接数，不考虑偏离 2 倍（10 行）太糟糕了。（错误会随着连接的数量呈指数增长）。
此外，优化器会尝试平衡制定计划所需的时间与潜在的节省——它不会花一整天的时间来寻找最佳计划。连接越多，存在的替代计划的数量就越多——其中一些可能比优化器有时间找到的更优化。
于 2008-10-31T20:12:17.657 回答
2
7 甚至更多在数据仓库中一点也不稀奇，因为事实表很容易拥有十几个维度的外键。在数据仓库场景中，维度的基数通常低于事实表，因此维度上的过滤器有助于通过索引查找或扫描来利用事实表。
对于规范化事务模式，如果结果集的基数在主基表中较低（即选择关于一个客户的所有内容）通常不是问题，因为外键通常可以简单地导致索引查找或索引扫描。
于 2008-11-01T01:13:12.230 回答
1
如果您的数据库设计需要，7 很好。但是，如果 7 是实现您的目标所必需的，我会重新检查数据库设计以确保这种模糊程度确实是必要的。
出于好奇，这是 DB2 吗？只是我注意到的一个模式:)
于 2008-10-31T19:12:38.760 回答
1
这是同一张表上的 7 个内连接，不同表上的 7 个内连接，还是 7 个嵌套内连接？
...诡计问题！没关系，如果这是您的数据库结构所需要的，那么它是正确的
警告：如果它是同一张表上的 7 个嵌套内部连接，则您可能有一个结构不良的表；-)
于 2008-10-31T19:28:35.687 回答
1
这当然不是不寻常的。然而，至少在 Oracle 中，7 是一个特殊的数字，因为超过这个数字，优化器就不能再测试每个连接顺序（由于可能性数量的阶乘增长）。因此，除非您准备好照看您的执行计划，否则避免超过 7 是明智的。
于 2008-10-31T20:15:14.313 回答
0
我认为您要避免的是大于 7 的连接深度。深度小于 7 的 7 个内部连接肯定不是闻所未闻，但有时人们听到“7 连接”并认为禁止是 7 连接，不是深度。
于 2008-10-31T19:08:05.180 回答