通过大量连接提高视图的性能

时间:2009-12-17 21:11:06

标签: sql-server join performance left-join

我有一个视图,它使用11个外部联接和两个内部联接来创建数据。这导致超过800万行。当我在桌子上进行计数(*)时,运行大约需要5分钟。我不知道如何提高这个表的性能。有没有人对从哪里开始有任何建议?在所有正在加入的列上似乎都有索引(虽然有些是复合,但不确定是否会产生影响......)

任何帮助表示感谢。

5 个答案:

答案 0 :(得分:4)

这是一个很难的,有了复杂的视图,你也可能会对视图进行查询,因此保证合理的性能会非常困难。视图中的外连接(尤其是复杂的连接)也容易给查询优化器带来麻烦。

一个选项是实现视图(在SQL Server上称为“索引视图”)。但是,您可能需要监视更新性能以检查它是否不会产生太多开销。此外,物化视图中的外连接可能会妨碍实时刷新;如果您需要这个,那么您可能必须将视图重新实现为非规范化表并使用触发器维护数据。

另一种可能性是检查视图是否可以分成两个或三个更简单的视图,可能实现一些但不是全部视图。实现某些视图并从系统中获得性能可能更容易。

答案 1 :(得分:2)

你的基本前提是错误的。 拥有返回800万行的视图并不是一个好主意,因为实际上你无法对这么多数据做任何事情。 因为所有这些连接,5分钟对于800万计数()来说听起来相当不错。

您需要做的是考虑您的业务问题并编写较小的查询/视图。

答案 2 :(得分:1)

您可以考虑的一些事项:

  1. denormalisation。减少非规范化数据结构所需的连接数
  2. 分区。你能从大表中分区数据吗?例如一个大表,如果分区为许多较小的表,可以表现得更好。从SQL 2005开始的企业版对分区有很好的支持,请参阅here。如果你开始进入数百万行的10s / 100s领域,可以考虑这个。
  3. 索引管理/统计。所有索引是否已整理碎片?统计数据是最新的吗?

答案 3 :(得分:1)

运行sql profiler / index调整向导。有时它会使索引建议不会立即变得有意义,但结果会产生很好的性能优势

答案 4 :(得分:0)

也许您尝试(外部)加入的某些表格是不相交的?如果是这样,请考虑创建存储过程而不是查看并创建如下内容:

select ... into #set1 from T1 left join T2 left join... where ...

select ... into #set2 from T3 left join T4 left join... where ...

...

select ... from #set1 left join #set2 left join ...

有了这个,您可以避免处理大量数据。当您进行外连接时,优化器通常无法在查询的解析树中向下移动选择(如果这样做,您将不会获得您可能想要的具有空值的行)

当然,您无法通过加入存储过程来创建查询。这只是您可以使用的基本想法。

相关问题