我最近接手一个项目，他们有一个SQL作业设置运行每三个小时，其重建ASP.NET成员资格数据库表中找到的索引。
这似乎是相当高的，重建索引每天8次。 我得到的每一天，共约2亿注册用户约2000新用户。
你会推荐合适的索引重建时间表是什么？
Answer 1:
您的死锁绝对可以进行相关的指标的重建。 也有毫无疑问，这些指标并不需要频繁地重建这一点。 最起码，虽然你应该考虑使用，如果你可以在在线选项，以保证指数从它的重建之前被丢弃。
下面是我们使用的指导原则：
当索引碎片是大于40％的指数应该被重建。 当索引碎片是40％至10％之间指数应重组。 索引重建过程中使用更多的CPU和它锁定数据库资源。 SQL Server开发版和企业版有选择ONLINE，它可以在重建索引被打开。 ONLINE选项将保留重建过程中可用的索引。
来源： http://blog.sqlauthority.com/2007/12/22/sql-server-difference-between-index-rebuild-and-index-reorganize-explained-with-t-sql-script/
Answer 2:
一个好的经验法则是REBUILD时，超过30％的分散，10％和30％之间时REORGANIZE。
不要用任何的表小于1000页打扰，你不会注意到，即使运行重建为一个超过30％，则往往在30％留后。
或许你也应该旨在重建/重组相当频繁，每周最多，平均数据库。 如果你有更频繁地比，那么你可能需要进行碎片整理的索引重新看个够因素和填充。
一个例外是后批量数据加载，它可能会在通用已经支离破碎索引（有时其更好地禁用索引或删除索引，重建或将取决于所加载的数据）。
因此，在总结，每天8次似乎过度。
参考文献：
http://technet.microsoft.com/en-us/library/ms189858.aspx
http://www.sqlmusings.com/2009/03/15/a-more-effective-selective-index-rebuildreorganize-strategy/
http://realworlddba.wordpress.com/2008/01/27/indexes-to-rebuild-or-reorganize/
http://realworlddba.wordpress.com/2008/01/27/indexes-to-rebuild-or-reorganize/
Answer 3:
捕获死锁图形，你有什么是死锁的实际答案，而不是猜测 。 鉴于僵局的（或至少应该是）一个相当罕见的occurence（在10 /秒），你可以很安全地连接Profiler在很长一段时间，并只捕获锁/死锁图形事件。
Answer 4:
是否重建伤了系统的稳定性或需要太多的系统时间？
如果你回答不 - 不要去碰它:)
文章来源: SQL Server 2005 - How often should you rebuild Indexes?
