MS SQL Datawarehouse对非唯一密钥表的性能改进

Question

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

对于使用许多这些视图的复杂查询，我们显然有一个问题，即多次连接相同的访问控制表。由于有很多查询我们无法控制访问此资源，因此目前我们无法做很多工作。因此，我们需要对盒子本身做出任何改变，以优化访问速度。

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

我们的问题是，尽管在这个非唯一记录（UserID列）上有一个索引，但在执行计划跟踪时，我们看到Table Scans被用来代替Index Seek，我知道它基本上忽略了指数。这导致了可怕的性能影响 - 上周的一项质询表示，执行一分钟现在可能需要10分钟，有些则推迟了一个小时。

现在引用此表的所有其他视图都会加入非索引列（帐户ID），然后基于用户的NT ID筛选出返回的帐户数。

有没有人有什么建议，我们可以做些什么来提高性能？无论是在短期内（我们可以在基础设施方面改变的东西），还是长期的（对数据库模式的改变，尽管考虑到数据库的使用方式，我们不能轻易做到这一点）。

谢谢！

大卫

Answer 1

如果你能，你应该为你的用户与作为遵循存储过程：

1. 创建一个临时表中的“老办法”（不连接）
2. 过滤器用户允许看到的结果

所以你只会加入相关数据。

它将大大提高查询时间（取决于数据库大小和相关数据量之间的比率），并且不需要更改数据库方案。

Answer 2

这听起来像你有一个UserId索引，但不是实际用于连接的AccountId。

如果我理解正确的指标，你可能尝试几件事情：

• 上ACCOUNTID添加索引 - 实验集群/非集群，看看这会对性能更好的影响。
• 更新UserId索引以包含AccountId - 如果两个字段总是一起使用，这可能会更好。

此外，在审查执行计划时，请查看查找详细信息 - 它在寻求什么？这可以帮助您进一步完善系统的理想指标。

祝你好运！

Answer 3

不幸的是，你正在使用的报表工具，你不提（我的印象中，用户写自己的查询？）还是什么量你有数据的，但有两个长期的改进将是：

1. 升级到SQL2008：SQL2000不再支持和性能，工具和一般特征都显著在新版本中
2. 提高使用像SSRS，Business Objects公司或COGNOS报告工具，包括用于用户级数据可视性支持，用于表演等的缓存。