有人可以解释一下这个问题吗?
在我们的开发箱中,我们的数据库完全驻留在 PRIMARY 文件组中,并且一切运行正常。
在我们最近从 2005 升级到 2008 的一台生产服务器上,我们注意到它的运行速度比应有的慢。在这台机器上,有两个文件组 - PRIMARY 和 INDEXES。这两个文件组每个逻辑卷包含 1 个文件,每个 CPU 包含一个逻辑卷(每个逻辑卷都是由 4 个物理磁盘组成的 RAID 10)。
我们隔离了一些在开发机上运行速度快而在生产机上运行速度慢(最多慢 40 倍)的查询。结果发现这些查询使用的是 INDEXES 文件组中的非聚集索引。调整一些查询以仅使用 PRIMARY 文件组中的聚集索引后,它们的时间恢复正常。
作为最后的确认,我们在同一台机器上重新部署了同一个数据库,使所有内容都处于 PRIMARY 状态,一切恢复正常!
下面是其中一个查询的统计输出,在具有不同文件组配置的机器上以相同的方式运行(表名已更改以保护无辜者):
FAST(PRIMARY 文件组中的所有内容):
(3 row(s) affected)
Table '0'. Scan count 2, logical reads 14, ...
Table '1'. Scan count 0, logical reads 0, ...
Table '1'. Scan count 0, logical reads 0, ...
Table '2'. Scan count 2, logical reads 7, ...
Table '3'. Scan count 2, logical reads 1012, ...
Table '4'. Scan count 1, logical reads 3, ...
SQL Server Execution Times:
CPU time = 437 ms, elapsed time = 445 ms.
速度慢(索引拆分到自己的文件组中):
(3 row(s) affected)
Table '0'. Scan count 209, logical reads 428, ...
Table '1'. Scan count 0, logical reads 0,...
Table '2'. Scan count 1021, logical reads 9043,....
Table '3'. Scan count 209, logical reads 105754, ....
Table '4'. Scan count 0, logical reads 0, ....
Table '5'. Scan count 1, logical reads 695, ...
**Table '#46DA8CA9'. Scan count 205, logical reads 205, ...**
Table '6'. Scan count 6, logical reads 436, ...
Table '7'. Scan count 1, logical reads 12,....
SQL Server Execution Times:
CPU time = 17581 ms, elapsed time = 17595 ms.
请注意慢查询中涉及的奇怪的临时表和额外表。显然,拥有第二个文件组会让 SQL Server 在选择执行计划时变得很疯狂。到底发生了什么?
答案1
我认为非聚集索引位于不同的文件组上这一事实在这里无关紧要,从上面的 STATISTICS IO 输出可以清楚地看出您有两个非常不同的执行计划。
从 SQL 2005 升级到 SQL 2008 后,您是否重建了索引并更新了统计信息?如果没有,您应该尽快这样做。如果您可以发布两次运行的执行计划(以及来自开发框的计划),可能会提供更多见解。