我创建了一个脚本，该脚本每晚运行以根据碎片重建和重新组织索引，重建碎片 > 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 磨机 + 记录数。
我的问题是：为什么重新组织索引不能更正索引中的记录计数和碎片以及首先导致该记录计数值在索引上变得如此过时的原因是什么？
我现在的计划是今晚强制重建所有索引，然后按照正常方式运行我的脚本。我应该担心索引记录计数再次过时吗？
重组索引不会更新索引的统计信息。Reorganize 将确保 B+ 树是平衡的，因为 SQL Server 在操作期间不会自动平衡树。重建索引将重新创建索引，允许引擎更新索引的统计信息。
您应该考虑定期重新组织和更新轻度碎片查询的统计信息，这样您就可以节省维护时间。如果您的数据足够同质，您还可以尝试使用样本定期更新统计信息。
您可以在此处阅读有关更新统计信息的更多信息
http://msdn.microsoft.com/en-us/library/ms187348.aspx
Kimberly Tripp 在http://sqlskills.com上发表了大量关于索引维护的博客
查看她的统计和索引链接。
感谢您的回答，我最终使用了那里的脚本
http://ola.hallengren.com/
一定是我的脚本不适合例如 xml 列的东西，现在一切都很好。
有时索引和/或统计信息不是最新的，因此 SQL 重新索引作业无法确定索引是否碎片化。
预先运行
DBCC UPDATEUSAGE将确保根据碎片级别重新创建或重组索引。