我仅次于乔纳森所说的一切-除了索引维护的频率。

好吧，如果您碰巧设计的索引不正确（例如GUID键上的聚集索引），则实际上可能至少需要在每个晚上（甚至在白天）执行此操作。

作为一般经验法则：如果您的索引碎片低于5％，则一切正常。如果您的碎片在5％到大约之间。30％，您应该进行索引重组：

ALTER INDEX (your index name) ON (your table name) REORGANIZE

如果索引的索引碎片超过30％，则需要完全重建它：

ALTER INDEX (your index name) ON (your table name) REBUILD

重建索引可能会造成破坏-尝试在下班时间（例如晚上）进行索引。

为了确定索引碎片，可以使用此DMV查询：

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

Michelle Ufford具有出色的自动索引碎片整理脚本-强烈建议！否则，您应该考虑设置可以每晚运行的SQL
Server维护计划，并清理索引。

马克