我仅次于乔纳森所说的一切-除了索引维护的频率。
好吧，如果您碰巧设计的索引不正确（例如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维护计划，并清理索引。
马克
602392714
清零编程群