在具有 1.28 亿行的表上重建索引答案

【问题标题】：Rebuild Index on table with 128 million rows在具有 1.28 亿行的表上重建索引
【发布时间】：2014-09-01 22:30:52
【问题描述】：

我有一个包含超过 1.28 亿行的数据库表。

我必须处理的问题是索引，随着时间的推移，数据库的性能非常糟糕，我将其部分归结为索引变得碎片化。大表上的当前索引之一是大约 50% 的总碎片。

重组在 1 小时内完成了大约 1%，因此需要的时间太长了。

在这么大的表上，重新索引可能需要 5 个小时甚至更多时间，而且我还没有找到监控进度的真正方法。在如此大的表上重新构建索引的最佳和最快方法是什么？我应该将数据库设置为“离线”吗？

该数据库还运行着一个非常庞大且繁忙的网站，因此我安排了最多 6 小时的停机时间来完成这项工作，但需要尽可能最快和最好的方式来完成这项工作。

我还需要更新数据库上的所有其他索引，但这张表是最难的。

【问题讨论】：

您是否通过分析前后性能实际测量了重建索引带来的显着性能改进？如果是这样，新索引和 50% 碎片索引之间的 OLTP 性能差异是多少？ DBA 经常重建索引只是因为他们认为应该这样做。索引被设计为在其中包含一些“膨胀/碎片”，尝试不断对其进行碎片整理通常是徒劳的。
老实说，我还没有在新索引和旧索引之间进行真正的性能测试，我所知道的是，通常在这样做之后，我们在系统上运行的缓慢查询和报告得到快很多。在此表上超过 1 年未进行过重建或重新组织。我不知道 OLTP 这个词，抱歉！
@Aki：OLTP = 在线事务处理。 OLTP 工作负载的特点是大量的小读取和读/写混合，例如为网站服务的数据库的典型特征。您可能会考虑只更新统计信息（索引重建也会这样做）。陈旧的统计数据可能会导致执行计划欠佳，从而降低性能。

【解决方案1】：

如果您还没有在这个特定索引上测量以下 2 件事，那么您可能还没有重建的理由。

B-Tree 索引旨在具有碎片/膨胀/可用空间。索引通常会很快恢复到其稳定的碎片状态。他们通常在这种状态下表现得体，往往想要回到稳定状态。

【讨论】：

问题是，我手头没有这类信息，因为我们没有记录过去重建的结果。有没有办法在没有先前结果的情况下确定是否需要重新索引？
您必须衡量查询时间。这正是我的观点。您在没有证明其好处的情况下承诺进行一项非常昂贵的操作。您应该编写一些测试查询并在之前和之后对它们进行计时。 Google 上有大量关于如何分析查询的信息。