在我们的SQL Server数据库中应该多久重建一次索引？

Question

目前，我们的数据库大小为10 GB，并且以每月约3 GB的速度增长。我经常听说人们应该时不时地重建索引，以改善查询执行时间。那么，在给定的场景中，我应该多久重建一次索引呢？

Answer 1

有一个普遍的共识是，一旦索引碎片超过5(有时是10%)，你就应该重新组织(“碎片整理”)你的索引，当它超过30%时，你应该完全重建它们(至少这是我在很多地方听到的主张的数字)。

米歇尔·乌福德(又名"SQL Fool")有一个automated index defrag script，它使用那些精确的限制来决定何时重组或重建索引。

另请参阅Brad McGehee's tips on rebuild indexes，其中有一些关于如何处理索引重建的好想法和技巧。

我在这里使用这个脚本(不记得我是什么时候得到这个的--不管是谁:非常感谢！)非常有用的东西)来显示给定数据库中所有索引的索引碎片：

SELECT 
    t.NAME 'Table name',
    i.NAME 'Index name',
    ips.index_type_desc,
    ips.alloc_unit_type_desc,
    ips.index_depth,
    ips.index_level,
    ips.avg_fragmentation_in_percent,
    ips.fragment_count,
    ips.avg_fragment_size_in_pages,
    ips.page_count,
    ips.avg_page_space_used_in_percent,
    ips.record_count,
    ips.ghost_record_count,
    ips.Version_ghost_record_count,
    ips.min_record_size_in_bytes,
    ips.max_record_size_in_bytes,
    ips.avg_record_size_in_bytes,
    ips.forwarded_record_count
FROM 
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') ips
INNER JOIN  
    sys.tables t ON ips.OBJECT_ID = t.Object_ID
INNER JOIN  
    sys.indexes i ON ips.index_id = i.index_id AND ips.OBJECT_ID = i.object_id
WHERE
    AVG_FRAGMENTATION_IN_PERCENT > 0.0
ORDER BY
    AVG_FRAGMENTATION_IN_PERCENT, fragment_count

Answer 2

“当你需要的时候”和“当你可以的时候”！

例如..。

• 首先测试碎片，并决定是什么都不做、重组还是重建。例如，SQL Fool's script does this有@minFragmentation和@rebuildThreshold参数，
• 每天进行统计，但在周末进行索引。您的维护窗口是多少？

Answer 3

您应该经常重建索引，以便生产不会受到索引降级的不利影响。我知道这看起来很模糊，但所有的数据库都是不同的，使用的方式也不同。您只需要定期重建/整理引起写操作(插入/更新)的索引-您的静态或主要只读的表将不需要太多的重建索引。

您将需要使用dbcc showcontig([Table])来检查索引的碎片级别，确定它们变得碎片的频率以及碎片的实际级别。

当索引变得过于碎片化(超过20%-30%左右)时，可以使用dbcc dbreindex([Table])完全重建索引，但如果您找不到足够大的停机时间窗口，并且碎片级别相对较低(1%-25%)，则应该使用dbcc indexdefrag([Database], [Table], [Index])对索引进行“在线”碎片整理。还请记住，您可以停止索引碎片整理操作，并在以后再次启动它，而不会丢失任何工作。

要使数据库及其索引“保持一致”，需要进行一些监视，以便真正了解何时以及重新索引的内容。