作为MS SQL 2000和2005的DBA,我经常看到巨大的选择查询JOINing 7-10甚至更多表.但是,我发现,性能往往会受到影响,并且查询变得非常难以调试和/或改进.
因此,当我应该考虑其他查询方法时,有一个"经验法则",比如临时表来保存初步结果吗？或者有一点之后,SQL查询优化器只是没有很好地找出最佳计划？
很多时候你可以通过创建帮助视图来减轻视觉气味,我认为没有一个严格的快速规则来判断有多少连接被认为是坏的.
与过程编码不同,将SQL分解成一些小块可能会导致查询效率低下.
SQL Optimiser可以很好地处理大量的表连接,如果你碰到一个角落的情况,你可以使用提示指定连接顺序或样式.实际上,我认为获得加入超过10个表的查询是非常罕见的,但是在报告类型场景中这可能发生这种情况是非常可行的.
如果您发现有大量连接的情况并且发现此特定查询是瓶颈并且您已准备好所有正确的索引,则可能需要重构.但是,请记住,大量连接可能只是一个症状,而不是问题的根本原因.应遵循查询优化的标准做法(查看分析器,查询计划,数据库结构,逻辑等)
SQL Server无论如何都使用tempdb进行合并连接,因此通常不需要创建临时表来重构单个SELECT查询.
| 归档时间： |
|
| 查看次数： |
15248 次 |
| 最近记录： |