SQL Server 2005 - 你应该多久重建索引？

Question

7

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

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

您会建议什么样的适当索引重建时间表呢？

- Jack Marchetti

4个回答

6

一个好的经验法则是，当碎片化超过30％时，请重新构建（REBUILD），当在10％和30％之间时，请重新组织（REORGANIZE）。

对于小于1000页的表格，不要费心，你不会注意到任何变化，即使对于超过30％的表格运行了REBUILD，它通常也会停留在30％左右。

你应该尽量少地进行重建/重新组织，对于普通数据库而言，最多每周一次。如果你需要比这更频繁地进行索引碎片整理，那么你可能需要重新考虑填充因子和填充量。

一个例外是在批量数据加载后，索引可能会被碎片化（有时禁用索引或删除索引并重建或根据正在加载的数据来选择是否重建更好）。

总之，一天8次似乎过于频繁了。

- Chris Chilvers

3

捕获死锁图，你就可以得到一个实际的答案，知道是什么造成了死锁，而不是猜测。考虑到死锁应该是相当罕见的情况（每秒少于10次），你可以安全地长时间附加分析器，并且只捕获Locks/Deadlock Graph事件。

- Remus Rusanu

0

重建会影响系统稳定性或占用太多系统时间吗？

如果你的回答是否定的 - 不要碰它 :)

- ilya.devyatovsky

似乎并不是这样，但我一天中会遇到一些与新用户注册相关的死锁问题。我想知道这是否是由于索引重建引起的。 - Jack Marchetti

取决于您是进行在线重建还是离线重建。如果是离线重建，则可能会导致死锁，因为它会在索引上放置读锁。如果是在线重建，则仅在索引上放置模式锁。 - Chris Chilvers

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- apiguy · Accepted Answer

你的死锁问题可能与索引重建有关，毫无疑问，这些索引不需要那么频繁地重建。但无论如何，如果可以，请考虑使用 ONLINE 选项以避免在重建索引之前删除该索引。

以下是我们使用的指南：

索引碎片化大于40％时，应重建索引。索引碎片化在10％至40％之间时，应重新组织索引。索引重建过程使用更多的CPU资源，并锁定数据库资源。 SQL Server开发版本和企业版本具有ONLINE选项，在重建索引时可以打开该选项。 ONLINE选项将保持索引在重建期间可用。