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

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

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

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

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

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

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

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

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

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

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