数据库索引-维护作业

Question

我创建了一个每晚运行的脚本来重建和重新组织基于碎片的索引，> 30%的索引被重建，10% - 30%的碎片的索引被重新组织。

在运行脚本之后，我注意到大约有400个索引仍然反映了> 10%的碎片计数，经过更多的调查后，我看到了一些帖子，其中提到页面数< 1000的索引不会被SQL重新组织。

我进一步研究了为什么我的脚本没有更新我的所有索引，并发现查询的结果

sys.dm_db_index_physical_stats(DB_ID(DB_NAME()),NULL,NULL,NULL, 'DETAILED')

显示页计数为5，6，对于有>1磨记录的表，record_count列有大约16 000条记录，然后通过运行索引强制进行索引重建。

ALTER INDEX [indexname] ON [schema].[table] REBUILD WITH (FILLFACTOR = 85, STATISTICS_NORECOMPUTE = OFF)

我的指数现在显示了1 mill +记录计数。

我的问题是:为什么索引的重新组织不纠正索引中的记录计数和分段&是什么导致这个记录计数值在索引上如此过时？

我现在的计划是今晚强制重建所有索引&然后按照正常的方式运行我的脚本。我是否应该担心指数记录会再次过时？

Answer 1

谢谢你的回答，最后我用了一个脚本

http://ola.hallengren.com/

这肯定是我的脚本不适合例如xml列的地方，现在都运行得很好。

Answer 2

重新组织索引不会更新索引上的统计信息。重新组织将确保B+树是平衡的，因为Server在操作期间不会自动平衡树。重新生成索引将重新创建索引，允许引擎更新索引上的统计信息。

如果您可以节省维护时间，您应该考虑定期地重新组织和更新关于松散的查询的统计信息。如果数据足够同质，也可以尝试使用示例定期更新统计数据。

您可以在这里阅读更多有关更新统计信息的信息。

http://msdn.microsoft.com/en-us/library/ms187348.aspx

金伯利?特里普在http://sqlskills.com上发表大量关于索引维护的博客

查看她的统计和指数链接。

Answer 3

有时索引和/或统计数据并不是最新的，因此SQL重新索引作业无法确定索引是否是支离破碎的。

预先运行DBCC UPDATEUSAGE将确保索引随后根据碎片级别重新创建或重新组织。