Index Seek和Index Scan的区别以及适用情况_index scan index seek

Index Seek就是SQL在查询的时候利用建立的索引进行扫描，即先扫描索引节点，即遍历索引树，在查找到相应叶子节点后，对于聚簇索引是直接取值叶子节点，而对于非聚簇索引是根据叶子节点中rowid去查找相应的行。而对于Index Scan是从头到位遍历整张数据表的所有行，从头到尾，因此在数据量很大时效率并不是很高(在Index是聚簇索引的情况，在是非聚簇索引的情况下呢)。

     SQL有一个查询优化分析器 Query Optimizer，其在执行查询之前首先会进行分析，当查询中有可以利用的索引时，其会优先分析使用Index Seek进行查询的效率，在使用Index Seek查询效率并不好的情况下，其会使用Index Scan进行查询。那究竟是在什么情况下会造成Index Seek效率比Index Scan还低呢？

1.在要查询的表中数据不是很多的话，使用Index Seek效率不一定高，因此使用Index seek还要先从索引树开始，然后再利用叶子节点去查找相应的行。在行树比较少的情况下，还没有直接进行Index scan快。

 2.在返回的数据量大的情况下，在返回的数据量占总数据量的50%或者超过50%则使用Index Seek效率不一定好，在返回的数据量占10%-15%时，利用Index Seek能获得最佳的性能。

 3.在建立索引的列的取值很多是一致的情况下，建立索引不一定能获得很好的效率。其实理由很简单，当建立索引的列取值的变化少的情况下，建立的索引二叉树应该是矮胖型的，树层次不高，很多行的信息都包含在叶子上，这样的查询显然是不能很好的利用到索引。

MSDN原话：不要总是将索引的使用等同于良好的性能，或者将良好的性能等同于索引的高效使用。如果只要使用索引就能获得最佳性能，那查询优化器的工作就简单了。但事实上，不正确的索引选择并不能获得最佳性能。因此，查询优化器的任务是只在索引或索引组合能提高性能时才选择它，而在索引检索有碍性能时则避免使用它。