SQL 文件组降低性能

Question

在我们的开发设备上，我们的数据库完全位于 PRIMARY 文件组中，并且一切正常。

在我们最近从 2005 年升级到 2008 年的其中一台生产服务器上，我们注意到它的性能比预期的要慢。在这台机器上，有两个文件组 - PRIMARY 和 INDEXES。两个文件组每个逻辑卷包含 1 个文件，每个 CPU 包含一个逻辑卷。文件组共享逻辑卷（它们都分布在所有磁盘上）。

我们隔离了一些在开发机器上执行速度快而在生产机器上执行速度慢（最多慢 40 倍）的查询。原来这些查询使用的是驻留在 INDEXES 文件组中的非聚集索引。将某些查询调整为仅使用位于 PRIMARY 文件组中的聚集索引，从而使它们的时间恢复正常。

作为最后的确认，我们在同一台机器上重新部署了同一个数据库，让一切都在 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 在选择执行计划方面变得困难重重。查看每个配置中查询的相应执行计划可以验证这一点，它们是完全不同的。

这是怎么回事？任何见解将不胜感激。

Answer 1

随意的想法

• 重建到新文件组时统计信息等未禁用？
• 维护任务不看文件组吗？
• 磁盘碎片严重？
• 尝试 MAXDOP 1
• 填充因子等完全相同吗？

IO 看起来很不对劲，所以我想知道统计数据或碎片是否导致了问题