mysql优化探索（5）在mysql中正确的创建索引2（sql优化）

一、这篇文章是上篇文章的延续，学习一下mysql什么时候用不到索引

1.使用like 然后跟开头有%的模糊查询时用不到索引，比如：

explain select * from actor where last_name like '%NI%'\G这条语句是用不到索引的，因为B-Tree索引的结构没法使用模糊匹配：

解决方法就是用全文索引，或者使用Innodb存储引擎的表的聚簇表特点进行处理。这里我们先说一下什么是聚簇索引，在Innodb存储表，都存在一个聚簇索引，比如主键和唯一id，或者建表时自动建立的row-id行。而聚簇索引和普通索引关系是：一个普通索引一定包含着聚簇索引。

根据以上描述，我们就可以改写上面的sql了，我们先使用last_name列上的idx_actor_last_name索引查出匹配 like '%NI%'的聚簇索引字段，也就是actor_id字段，因为这个字段是聚簇索引，所以要比查询全表快的多，然后再从匹配的记录中用获取的聚簇索引字段actor_id查找整个表，这样会比扫描全表找模糊匹配快的多。

explain select * from (select actor_id from actor where last_name like '%NI%') a, actor b where a.actor_id=b.actor_id\G

2.数据类型隐式转换了不会用到索引，比如某个字段是字符类型，而你写sql时赋值了个没有带引号的数字，这个时候就不会用到索引：

3.复合索引，不包含最左原则不会用到索引

4.如果mysql估计扫描全表时要比扫描索引时性能更好就不会用索引扫描。

5.用or关键字查询时，or前后的列索引有或者没有的状态不统一不会用到索引，比如or前面的列有索引，or后面的列没索引这样就不会用到索引。

二、查看mysql使用索引的情况。

1.Handler_read_key的值代表一个行被索引值读取的次数，这个值越高表用用到索引的效率高，如果这个值坻就需要改善索引了。

2.Handler_read_rnd_next的值代表数据文件中读下一行的请求数，这个值越高，说明用到索引的效率越低，如果这个值高的话就说明mysql正在挨顺序查找数据，这个时候我们也要改善索引了。

下面这种情况就说明索引的使用情况不佳：