MS SQL Data Warehouse对非唯一键表的性能改进

Question

我们最近更新了DataWarehouse（一个MS SQL 2000数据库），以包含一个新表来控制用户在所有其他表中访问信息的级别。新表没有太多细节，它有一个用户ID，以及一个可以访问的帐户ID列表。我们在DataWarehouse中的所有表都创建了相应的视图，并且我们已要求用户使用这些视图来访问数据（从而根据初始访问控制表中的访问级别限制其视图）。 / p>

对于使用其中许多视图的复杂查询，我们显然遇到了一个问题，即多次连接相同的访问控制表。我们目前无法做很多事情，因为有许多查询我们无法控制访问此资源。因此，我们需要对盒子本身进行任何更改，以优化访问速度。

Datawarehouse只在一夜之间更新，说实话，这个时间无关紧要 - 不需要插入速度，只需选择。如果需要的话，我们也可以重建索引。

我们遇到的问题是，尽管在此非唯一记录（UserID列）上有索引，但在执行执行计划跟踪时，我们会看到使用表扫描而不是Index Seek，我理解基本上忽略了索引。这导致可怕的性能影响 - 上周花了一分钟执行的查询现在可能需要10分钟，有些人正在推动一小时。

现在引用此表的所有其他视图都会加入到非索引列（帐户ID），然后根据用户的NT ID过滤掉返回的帐户数。

有没有人对我们如何改善表现有任何建议？无论是在短期内（我们可以在基础架构方面改变的事情），还是更长期的（对数据库架构的更改，尽管考虑到数据库使用方式的性质，但我们不能轻易做到这一点。）

谢谢！

大卫

Answer 1

如果可以，您应该为您的用户提供如下操作的商店程序：

1. 创建一个临时表“旧方式”（没有连接）
2. 过滤用户允许查看的结果

因此您只会加入相关数据。

它将显着改善查询时间（取决于db的大小与相关数据量之间的比率），并且不需要更改db方案。

Answer 2

听起来你在UserId上有一个索引，但不是在连接中实际使用的AccountId。

如果我正确理解了您的索引，您可以尝试以下几点：

• 在AccountId上添加索引 - 使用clustered / non-clustered进行实验，看看哪个对性能有更好的影响。
• 更新UserId索引以包含AccountId - 如果总是一起使用2个字段，这可能会更好。

此外，在审查执行计划时，请查看搜索详细信息 - 它在寻求什么？这可以帮助您进一步优化系统的理想索引。

祝你好运！

Answer 3

不幸的是，您没有提到您正在使用的报告工具（我的印象是用户编写了自己的查询？）或者您拥有的数据量是多少，但两个长期增强功能将是：

1. 升级到SQL2008：不再支持SQL2000，性能，工具和常规功能在新版本中都得到了显着改善
2. 使用SSRS，Business Objects或Cognos等报告工具，其中包括对用户级数据可见性，性能缓存等的支持。