索引查找和索引扫描

索引的访问方式主要是 索引查找、索引扫描。

（1）索引查找

在执行计划中为 index seek，适用于查找少量数据。

对应随机IO，能快速的定位一条数据。

 

（2）索引扫描

在执行计划中为 index scan，适合扫描整个索引的数据。类似于全表扫描(只扫描索引)

对应顺序IO，IO效率本身比较高。

 

(3）效率对比

索引查找 和 索引扫描，单从IO效率上来说，肯定是索引扫描的效率更高，因为顺序IO的效率高于随机IO的效率。

但是一个索引查找消耗的时间，肯定要远小于索引扫描的时间，因为索引查找只是定位少量记录。

比如：

A表有100w条数据，有索引idx_A，那么查找1条记录，假设消耗的时间是0.00001秒，而扫描整个索引消耗时间是0.1秒（都为估算的时间）。

 

现在的sql：select * from A where id = 123456

查询1条数据，那么用索引查找就是0.0001秒，而索引扫描还是0.1秒。

 

如果sql是：select country（*） from A 

那么，索引扫描可以满足这个sql，消耗还是0.1秒，但如果用索引查找，0.00001* 100w = 100秒（估算值，不一定是线性增长的）。

所以，对于不同的sql，sql server优化器会决定是用index seek，还是index scan。

 

产生索引扫描的原因:

 

参考：https://www.cnblogs.com/kerrycode/p/4806236.html

1.隐式转换容易从索引查找变成索引扫描

 

我们可以通过两种方式避免SQL做隐式转换：

    1：确保比较的两者具有相同的数据类型。

    2：使用强制转换（explicit conversion）方式。

2.统计信息缺失或者不正确容易导致索引扫描

3.where子句中的谓词不是联合索引的第一列
对于联合索引最左边一列存有统计信息，其他列sqlserver不存统计信息

4.where 子句里串联  索引字段使用函数 / 进行计算   会导致索引失效
 where A+B = ... (索引为A，B联合索引)
解决方法：
1).A+B生成一个计算列
2).where A = ...and where b=...

5.=,>,<,>=,<=,between,已经部分like(like'%XXX') 可以使用索引查找

优化like查找：
1）在oracle中可以使用instr
select count(*) from table t where instr(t.code,'Cod2%') > 0
2）在mysql中可以用locate和position函数，
如field like '%AAA%'可以改为locate('AAA',field) > 0
或POSITION('AAA' IN field)>0。  
3）在sql server中，可以给字段建立全文索引，用contains来检索数据

4）这里多说一句，并不是所有%在前的模糊匹配都会走索引扫描

如果只select索引字段，或者select索引字段和主键，也会走索引的。（where条件匹配中%在前）

https://blog.csdn.net/weixin_38860565/article/details/103007033

6.where条件中使用标量函数回事索引查找转为索引扫描

7.隐式转换：表中的数据与where条件或者on条件的变量格式不一致，或者两个相关联的表的格式不一致