不加索引

没有索引，整张表读取数据，然后利用数据来比较条件，捞出符合条件的数据，表有很多数据，这些数据都会通过磁盘IO来读取，很耗时。

加索引

加索引后 ，通过索引可以找到主键，根据主键id去聚簇索引里读取数据，更准确的找到数据所在的页，减少磁盘IO。

索引失效

失效场景比较多，但基本的原则就是最左匹配原则，因为最左匹配原则会帮助我们来建立索引，针对多列索引的情况下，会根据多列中的第一列来建立索引树，基于索引树的知识我们来分析一下场景：

不符合最左匹配原则查询
explain select * from tb_user where b=1;

多列索引是 ：a，b 两列来建立索引，因为b这个字段在索引树中找不到，所以索引就用不上。

最左匹配中间断了
explain select * from tb_user where a=1 and c=3;

中间索引列 b字段断开了（带头索引生效，其他索引失效）,

not in

这个其实好理解，因为正向数据是命中机制，正向 in 查询是可以命中索引树的，反向操作是不会走索引树的，自然就相当于索引失效。

模糊查询

一般模糊查询有三种类型：

  • %a
  • %a%
  • a%

这三种前两种是不回走索引树的，因为无法匹配，

使用不等于（!=、<>）

一样，不符合最左匹配原则。

or 操作

用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。但是and不会受影响。

不要在索引上做任何操作（计算、函数、自动/手动类型转换），不然会导致索引失效而转向全表扫描

计算会让索引失效。

索引字段是字符串，但查询时不加单引号，会导致索引失效而转向全表扫描

这个就是有些奇怪

MySQL优化器的最终选择，不走索引

索引的选择，就会交由 优化器 来选择合适的索引。优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。当优化器觉得使用索引的成本比全表索引查询要更快的时候就不回选择索引，而是直接全表索引查找。这个不好验证，据一个例子，根据年纪查询，假设年纪已经加了索引，那么一下两个语句，可能第二个语句就没走索引，

select name,age from table_user where age > 89

select name,age from table_user where age > 0

毕竟age>89的人还是少数，但是大于0岁的就非常多。

总结

手段是加索引，目的是减少磁盘IO。

索引失效

MySQL索引失效原理是什么？MySQL的索引失效的情况《MySQL面试小抄》索引失效场景验证