缓慢的 SQL Server 数据库（约 2TB） - 由于索引碎片而导致 CPU 高？

Question

我已经在 ServerFault 上发布了这个，但没有多少运气得到回应。

我有一个相当大的 SQL Server 数据库（~2TB）。大多数数据都在一个表中（约 60 亿行）。

两周前，我在大表上删除了两个非聚集索引，并将数据迁移到单个 6TB RAID SSD 阵列上。然后我重新创建了两个需要很长时间的索引（假设因为我目前有数据（用于表和索引）并登录到同一个阵列上，似乎使用 RAID 我不能有快速的顺序和随机 r/w同时）。

无论如何，在重新创建索引后，它运行了大约一个星期。在这一周中，我一直在大桌子上慢慢清理，它只是删除了旧的不需要的行。到目前为止，我已经从 60 亿中删除了大约 3 亿，而且我猜测我还有很多事情要做。

现在像这样运行了大约一个星期后，它现在运行得很慢，我不确定哪个最好。

现在的情况：

• 双至强
• 192GB 内存
• 带有 SQL Server 2012 的 Windows Server 2012
• CPU 达到 100%（16 核）——在减速之前只使用了大约 50%
• IO 似乎不太努力（无队列）

大表目前有（我之前没有任何碎片信息）：

• 1x 聚集索引：48% 碎片化
• 1x 非聚集索引：36% 碎片化
• 1x 非聚集索引：10% 碎片
• 我以前在这个表上还有两个索引，但不久前删除了它们

你认为什么最能解决我的问题

• 在同一个数组上重建非聚集索引（假设这应该可以解决问题，但会像以前那样需要很长时间。在不久的将来可能会遇到同样的问题，因为我仍在清理表）
• 在新的 RAID 阵列上重建非聚集索引（应该如上所述修复但可能更快）
• 将非聚集索引移动到新的 RAID 阵列（最快选项）
• 在新的 RAID 阵列上重新创建两个旧索引（不确定这是否可以缓解 CPU 或 IO 压力）

碎片化的索引会导致更高的 CPU 使用率吗？

还有什么我可能会错过的吗？

TIA

Answer 1

与其查看索引，不如开始查看导致 CPU 使用率高的查询。从Michael J. Swart 的 DMV 查询开始，查找 CPU 使用率最高的查询。查看查询正在使用哪些索引，它们是否正在执行隐式转换等操作。但通常不会，碎片本身可能不会这样做。