Asp.net SQL Server 2005-应多久重建一次索引？

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

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

---

对于正确的索引重建计划，您有何建议？

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

---

如果您回答“否”-不要碰它：）

您的死锁肯定与重建索引有关。毫无疑问，这些索引不需要如此频繁地重建。不过，如果您可以在重建之前保持索引不被删除，那么您应该考虑使用联机选项。 以下是我们使用的指南：

索引时应重新生成索引 碎片大于40%。指数 索引时应重新组织 碎片在10%到40%之间。 索引重建过程使用更多CPU 并锁定数据库资源。 SQL Server开发版本和 企业版具有联机选项， 当索引为 重建。在线选项将保留索引 在重建期间可用

---

来源：

捕获死锁图，您就可以得到什么是死锁的实际答案，而不是猜测。考虑到死锁是（或至少应该是）一种相当罕见的情况（低于10/秒），您可以相当安全地在很长时间内附加探查器，并仅捕获事件。

一个好的经验法则是在超过30%碎片时重建，在10%和30%之间重新组织

您不会注意到，对于小于1000页的表，不必担心这两种情况，即使在为超过30%的表运行重建后，它通常也会保持在30%

对于一个普通的数据库，您可能应该尽量少重建/重新组织，最多每周一次。如果您必须更频繁地对索引进行碎片整理，那么您可能需要重新查看填充因子和填充

大容量数据加载后会出现一个例外情况，在这种情况下，索引可能很常见（有时最好禁用索引或删除索引，然后根据加载的数据进行重建）

因此，总的来说，每天8次似乎是多余的

参考文献：

---

似乎没有，但我确实在一天中遇到了一些与新用户注册相关的死锁问题。我想知道这是否是由于索引重建造成的。这取决于您是在进行联机重建还是脱机重建。如果它离线，那么是的，它会在索引上放置读锁时导致死锁。如果其处于联机状态，则只在索引上放置模式锁。