详细讲解SQL Server索引的性能问题[1]

在良好的数据库设计基础上能有效地使用索引是SQL Server取得高性能的基础SQL Server采用基于代价的优化模型它对每一个提交的有关表的查询决定是否使用索引或用哪一个索引因为查询执行的大部分开销是磁盘I/O使用索引提高性能的一个主要目标是避免全表扫描因为全表扫描需要从磁盘上读表的每一个数据页如果有索引指向数据值则查询只需读几次磁盘就可以了

所以如果建立了合理的索引优化器就能利用索引加速数据的查询过程但是索引并不总是提高系统的性能在增删改操作中索引的存在会增加一定的工作量因此在适当的地方增加适当的索引并从不合理的地方删除次优的索引将有助于优化那些性能较差的SQL Server应用实践表明合理的索引设计是建立在对各种查询的分析和预测上的只有正确地使索引与程序结合起来才能产生最佳的优化方案本文就SQL Server索引的性能问题进行了一些分析和实践

一聚簇索引（clustered indexes）的使用

聚簇索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序由于聚簇索引的索引页面指针指向数据页面所以使用聚簇索引查找数据几乎总是比使用非聚簇索引快每张表只能建一个聚簇索引并且建聚簇索引需要至少相当该表%的附加空间以存放该表的副本和索引中间页建立聚簇索引的思想是

大多数表都应该有聚簇索引或使用分区来降低对表尾页的竞争在一个高事务的环境中对最后一页的封锁严重影响系统的吞吐量

在聚簇索引下数据在物理上按顺序排在数据页上重复值也排在一起因而在那些包含范围检查（between<<=&gt;>=）或使用group by或order by的查询时一旦找到具有范围中第一个键值的行具有后续索引值的行保证物理上毗连在一起而不必进一步搜索避免了大范围扫描可以大大提高查询速度

在一个频繁发生插入操作的表上建立聚簇索引时不要建在具有单调上升值的列（如IDENTITY）上否则会经常引起封锁沖突

在聚簇索引中不要包含经常修改的列因为码值修改后数据行必须移动到新的位置

选择聚簇索引应基于where子句和连接操作的类型

[] [] [] [] [] []