MySQL索引优化实战

首先理解一下什么是"索引"----索引是一种排好序的数据结构，怎么理解排好序呢？日常现象中我们接触到的索引场景有哪些？比如我们在图书馆想要找一本书，这本书跟定有对应的编号，书名，我们直接搜索对应的属性，就能够快速的找到这本书在图书馆的第几层，哪个货架，第几排，第几列，这样我们就能够快速的找到这本书，找起来就不会很费劲，那这个找书的过程就相当于按照顺序去查找的过程。数据库中的索引也是相同的概念，它可以让服务器快速地定位到表的指定位置，然后快速的查询表中你想要的数据。

联合索引第一个字段就用范围查找不会走索引，MySQL会觉得第一个字段就用范围查找，结果集比较大，回表次数较大，还不如直接走全表扫描更快这个过程可以使用force index（idx_name_age_position）来强制走索引，不过通过开启trace工具分析可以知道，效率还是走全表扫描比较快

覆盖索引优化


**Explain** select name,age,position from employees  where name > 'Lilei' and age = 22 and position = 'manager';

查看sql语句的执行计划可知，用到索引

in 和or在数据量比较庞大的时候用到了索引，数据量比较小的时候会走全表扫描

like KK%一般情况下都会走索引

这种情况下是like KK% 走了索引下推，索引下推是MySQL5.6引入的一种减少回表的优化方式，对建立了联合索引的sql查询语句，能用索引就用索引。尽量避免全表扫描。

为什么范围查找Mysql没有用索引下推优化？

估计应该是Mysql认为范围查找过滤的结果集过大，like KK% 在绝大多数情况来看，过滤后的结果集比较小，所以这里Mysql选择给 like KK% 用了索引下推优化，当然这也不是绝对的，有时like KK% 也不一定就会走索引下推。

常见的sql优化

order By优化对比下面的两个sql语句

select * from employees where name = 'Lilei' and position = 'dev' order by age;

这条查询语句中，利用最左前缀法则，中间字段不能断，查询用到name索引列，排序用到age索引列，还有一个查询用到position索引列，因此在Extra字段中不会出现，using filesort.

select * from employees where name = 'Lilei'order by position;

从explain结果来看，查询用到 name索引，不过中间跳过了age 用position进行排序，因此在执行计划中，Extra字段会出现 using filesort

select* from empoyeees where name = 'Lilei' order by age,position;

这条sql语句中也是根据最左匹配原则来使用联合索引的索引列的，因此Extra字段中也不会出现 Using filesort

Mysql索引优化一