SQL Server 2005 - 您应该多久重建一次索引？答案

【问题标题】：SQL Server 2005 - How often should you rebuild Indexes?SQL Server 2005 - 您应该多久重建一次索引？
【发布时间】：2009-08-25 21:53:03
【问题描述】：

我最近接手了一个项目，他们有一个 SQL 作业设置，每三个小时运行一次，它会重建在 ASP.NET Membership 数据库表中找到的索引。

这似乎相当高，每天重建索引 8 次。我每天大约有 2000 个新用户，总共有大约 200 万注册用户。

对于适当的索引重建计划，您有什么建议？

【问题讨论】：

【解决方案1】：

您的死锁肯定与索引的重建有关。毫无疑问，这些索引不需要那么频繁地重建。如果可以的话，至少应该考虑使用 ONLINE 选项，以防止索引在重建之前被删除。

这是我们使用的指南：

索引时应该重建索引碎片率大于 40%。指数索引时应重新组织碎片化在 10% 到 40% 之间。索引重建过程使用更多 CPU 它会锁定数据库资源。 SQL Server 开发版和企业版有在线选项，可以在Index为重建。 ONLINE 选项将保留索引在重建期间可用。

【讨论】：

【解决方案2】：

一个好的经验法则是当超过 30% 的碎片化时重建，在 10% 到 30% 之间时重组。

不要为少于 1000 页的表格烦恼，您不会注意到，即使在对超过 30% 的表格运行 REBUILD 后，它通常也会保留在 30%。

您的目标可能应该是相当不频繁地重建/重组，对于普通数据库，最多每周一次。如果您不得不更频繁地对索引进行碎片整理，那么您可能需要重新查看填充因子和填充。

一个例外是在批量数据加载之后，索引碎片可能很常见（有时最好禁用索引或删除索引并重建或根据加载的数据重建）。

所以总而言之，一天 8 次确实有点过分了。

【讨论】：

【解决方案3】：

捕获死锁图，您就会得到关于什么是死锁的实际答案，而不是猜测。鉴于死锁是（或至少应该是）相当罕见的发生（低于 10/秒），您可以在很长一段时间内非常安全地附加分析器并仅捕获Locks/Deadlock Graph 事件。

【讨论】：

【解决方案4】：

重建是否会损害系统稳定性或占用太多系统时间？

如果你回答不 - 不要碰它:)

【讨论】：