重建完成后重建索引会导致性能下降吗？

Question

我们有一个严重碎片化的客户数据库——实际上每个超过 1000 页的表都有 >95% 的碎片。填充因子设置为合理的值，但页面空间使用量远不及大多数表的填充因子。

这是没有对数据库执行维护的结果。

使用Ola Hallengren 的 IndexOptimize重建索引可按预期减少碎片。在现有的生产硬件上，应用程序的性能按预期提高。我通常使用的所有指标——大量查询的客户端统计、分析器持续时间、读/写停顿、应用程序日志和用户感知——都表明性能得到了提高。

然而，支持英特尔 PCIe SSD 的新数据库服务器显示出与我们预期相反的情况。高度分散，应用程序运行良好。重建索引后，应用程序性能不佳。一些需要约 90 秒的操作现在需要约 6 分钟。但是，其他指标似乎都没有表明系统运行速度变慢。

这是其他人经历过的吗？

Answer 1

是的，重建索引（尤其是在 SSD 上）会导致性能下降。大多数高速 SSD 更喜欢更多、更小的块请求，而不是更少、更大的请求。这与传统的旋转锈病所喜欢的模式完全相反。

假设您有一个高度分散的 B 树。由于磁盘上没有任何命令，您通常会发出大量 8KB I/O 请求来扫描树。如果您要对树进行碎片整理，那么在单个请求中最多可以获得 512KB。这些大请求在 SSD 上会有更高的延迟，因为 SSD 在内部将其分解为 8KB 块（与硬盘驱动器不同，后者会发出顺序 I/O）。对于很多情况：更高的磁盘延迟 = 更慢的查询

话虽如此，请务必检查您是否确实获得了与重建之前获得的相同的查询计划。

最后：除非您的空间不足，否则当您在 SSD 上运行时，为什么要浪费宝贵的 DBA 时间进行索引重建？

Answer 2

高度分散，应用程序运行良好。重建索引后，应用程序性能不佳。

一个可能的原因是重建后结构的更改（可能减小）大小意味着优化器正在选择不同的计划。优化器成本计算模型的主要输入之一是每个计划操作员预计要处理的页数。

更改结构中的页数很容易在优化器选择散列或合并连接与嵌套循环（有或没有假脱机）策略之间产生差异。这只是一个例子；成本差异会影响计划选择的所有方面，包括是否使用并行性的决定。

为了产生您所观察到的那种性能差异（并考虑到缺乏物理 I/O），这似乎是最可能的解释（假设您可以消除“坏”参数嗅探）。

综上所述，如果没有详细信息（最好是重建前后单个问题实例的计划和详细指标），当前的问题可以说是非常基于意见的，这将使其脱离本网站的主题。