通常,DBMS会自动管理索引,以便它仍然有效。但是,通过足够的插入,删除和更新操作,可以想象索引中存在改进的空间。也就是说,如果删除并重新创建索引,则生成的索引将比修改后的索引更小且更有效。而且,最终,较小的索引意味着更少的I / O操作,并且I / O操作比计算昂贵得多。
可能有我不了解的特定于SQL Server的答案,但是:
我是乔纳森所说的第二件事 - 除了索引维护的频率。
好吧,如果您碰巧设计了一个设计不佳的索引(例如GUID键上的聚簇索引),您实际上可能至少每晚都需要这样做 - 甚至在白天也是如此。
一般的经验法则是:如果你的索引碎片低于5%,一切都很好。如果碎片在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维护计划 可以运行,例如每晚都清理你的指数。
渣