MySQL索引优化实战（一）

一、索引下推优化详解

我们在上一篇章中 提到 为什么like KK%相当于=常量，%KK和%KK% 相当于范围
这里用到了一个索引下推的概念
对于辅助的联合索引(name,age,position)，正常情况按照最左前缀原则，
SELECT * FROM employees WHERE name like ‘LiLei%’ AND age = 22 AND position =‘manager’
这种情况只会走name字段索引，因为根据name字段过滤完，得到的索引行里的age和position是无序的，无法很好的利用索引。

在MySQL5.6版本之前，查询过程是这样的：
首先会在联合索引树中匹配到”LiLei“开头的索引，然后拿这些匹配到的对应的主键挨个去做回表操作，去主键索引树找出对应的记录，再去比对age和position是否符合

在MySQL5.6版本之后，引入了索引下推优化，在联合索引遍历过程中，匹配到名字是 ‘LiLei’ 开头的索引之后，同时还会在索引里过滤age和position这两个字段，拿着过滤完剩下的索引对应的主键id再回表查整行数据（在索引遍历过程中，对索引中包含的所有字段先做判断，过滤掉不符合条件的记录之后再回表，可以有效的减少回表次数）

注意事项：索引下推会减少回表次数，对于innodb引擎的表索引下推只能用于二级索引，innodb的主键索引（聚簇索引）树叶子节点上保存的是全行数据，所以这个时候索引下推并不会起到减少查询全行数据的效果

那么问题来了，为什么范围查询的时候，没有使用索引下推优化，而like会使用呢？（mysql底层是C语言写的，得去捞mysql底层源码，这里猜测大概原因）

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

二、MySQL优化器索引选择探究

示例一：下图中执行计划分析sql语句可能会走联合索引，但是实际执行之后并没有走索引，这是为什么呢？

结论：联合索引第一个字段就用范围查找不会走索引，mysql内部可能觉得第一个字段就用范围，结果集应该很大，回表效率不高，还不如就全表扫描

优化方法：
1.走覆盖索引
2.用强制索引（force index(idx_name_age_position)）

虽然使用了强制走索引让联合索引第一个字段范围查找也走索引，扫描的行rows看上去也少了点，但是最终查找效率不一定比全表扫描高，因为回表效率不高

在表中插入10w条数据
‐‐ 关闭查询缓存
2 set global query_cache_size=0;
3 set global query_cache_type=0;
4 ‐‐ 执行时间0.333s
5 SELECT * FROM employees WHERE name > ‘LiLei’;
6 ‐‐ 执行时间0.444s
7 SELECT * FROM employees force index(idx_name_age_position) WHERE name > ‘LiLei’;
我们发现，强制走索引反而比全表扫描还慢一些

示列二：in和or在表数据量比较大的情况会走索引，在表记录不多的情况下会选择全表扫描（employees表中有10w条数据，employees_copy表中有3条数据）


我们可以看出，在数据量很小的时候，全表扫描比走索引会更加效率高

那么 mysql 是如何选择合适的索引的呢，我们继续往下看



可以看到同一张表，这两种 name>‘a’ 和 name>‘zzz’ 的执行结果，一个走了索引一个却没有走索引，mysql 到底是如何去判断的 ，我们用trace 工具来看（开启trace工具会影响mysql性能，所以只能临时分析sql使用，用完之后立即关闭）





从分析工具不难看出，mysql 在分析 sql 执行成本的时候，针对全表扫描的成本做出的 cost 值为 2052.6，而针对索引扫描的数据行虽然减少了，但是算出的 cost 值为 6000 多（可能回表次数多，索引下推次数多），所以最终选择全表扫描

三、索引优化order by 与 group by

sql 判断 Order by 是否走了索引，我们无法从 key_len 中判断，key_len 只会统计 where 中走了索引的字段长度，只能通过 Extra 去判断，如果是 using index 那就说明走了索引排序（using index condition 表示走了索引，但是没有完全覆盖，走了前置列），如果是Using filesort，将用外部排序而不是索引排序。
下面的表中建了联合索引（name,age,posiotion）
示例一：

分析：查询条件用了 name 索引，排序也用了索引排序，因为name 确定了，才能保证下一个索引字段 age 有序，才能得以索引排序

示例二：

分析：查询条件用到了 name 索引，但是跳过了 age，直接用了 position 排序,position此时是无序的，无法直接利用索引排序，只能取出结果集后去磁盘中排序

示例三：

分析：查找条件用到了 name，排序也按照最左原则用到了 age 和 position，所以会用到索引排序

示例四：

分析：查找条件用到了name，但是排序没有按照最左原则，所以无法利用索引排序，因为 position 无序的此时

示例五：

分析：查找用到了 name 和 age，排序用到了 position，所以里用到了索引排序，position 后面的 age 可以说等于没有

示例六：

分析 ：虽然排序的字段与索引顺序一致，但是 position 是倒序的，order by 默认是升序，索引的顺序和排序方式不同也无法利用索引排序（Mysql8以上版本有降序索引可以支持该种查询方式）

示例七：

分析：name是范围查询（in 可能走索引可能不走），但是 order by是绝对不会走索引，因为name 查询出的结果集就是无序的

示例八：

诶，按照我们的索引排序规则，此时 Order by 应该走索引排序啊 ，但是却没有，这是为什么呢？
分析：因为数据量太大了，mysql 底层分析之后发现，还不如全表扫描去磁盘排序来得快；因为数据量很大的时候，这里是查询的，所以还得去回表，mysql 底层分析得出还是全表扫描快，那么优化方式就很明显了，使用覆盖索引即可*

优化总结：
1、MySQL支持两种方式的排序filesort和index，Using index是指MySQL扫描索引本身完成排序。index 效率高，filesort效率低。
2、order by满足两种情况会使用Using index。
（1） order by语句使用索引最左前列。
（2） 使用where子句与order by子句条件列组合满足索引最左前列。
3、尽量在索引列上完成排序，遵循索引建立（索引创建的顺序）时的最左前缀法则。
4、如果order by的条件不在索引列上，就会产生Using filesort。
5、能用覆盖索引尽量用覆盖索引
6、group by与order by很类似，其实质是先排序后分组，遵照索引创建顺序的最左前缀法则。对于group by的优化如果不需要排序的可以加上order by null禁止排序。注意，where高于having，能写在where中 的限定条件就不要去having限定了。

四、Using filesort 文件排序详解

filesort文件排序方式有两种：
1.单路排序：是指将查询的所有列和排序字段全部放入一个排序内存（sort buffer）的空间去排序，排好序直接返回结果（用trace工具可 以看到sort_mode信息里显示
<sort_key, additional_fields>或者<sort_key,packed_additional_fields >）
2.双路排序（回表排序）：是将查询的列中的 id 和排序字段放入一个排序内存（sort buffer）空间去排序，排完顺序后用排好顺序的 id 去索引树上查询再返回（用trace工具 可以看到sort_mode信息里显示
< sort_key, rowid >）
优缺点：单路排序占用内存大一些，双路排序需要回表一次
MySQL 通过比较系统变量 max_length_for_sort_data(默认1024字节) 的大小和需要查询的字段总大小来 判断使用哪种排序模式。
如果 字段的总长度小于max_length_for_sort_data ，那么使用 单路排序模式；
如果 字段的总长度大于max_length_for_sort_data ，那么使用 双路排序模式。

如果查询的数据量超过 1kb，内存排序空间放不下了，mysql 会开辟几个临时文件放在磁盘上把数据放磁盘上，然后再一起放到内存中去排序，所以才有临时文件的概念

我们先看单路排序的详细过程：

1. 从索引name找到第一个满足 name = ‘zhuge’ 条件的主键 id
2. 根据主键 id 取出整行，取出所有字段的值，存入 sort_buffer 中
3. 从索引name找到下一个满足 name = ‘zhuge’ 条件的主键 id
4. 重复步骤 2、3 直到不满足 name = ‘zhuge’
5. 对 sort_buffer 中的数据按照字段 position 进行排序
6. 返回结果给客户端

我们再看下双路排序的详细过程：

1. 从索引 name 找到第一个满足 name = ‘zhuge’ 的主键id
2. 根据主键 id 取出整行，把排序字段 position 和主键 id 这两个字段放到 sort buffer 中
3. 从索引 name 取下一个满足 name = ‘zhuge’ 记录的主键 id
4. 重复 3、4 直到不满足 name = ‘zhuge’
5. 对 sort_buffer 中的字段 position 和主键 id 按照字段 position 进行排序
6. 遍历排序好的 id 和字段 position，按照 id 的值回到原表中取出 所有字段的值返回给客户端

其实对比两个排序模式，单路排序会把所有需要查询的字段都放到 sort buffer 中，而双路排序只会把主键 和需要排序的字段放到 sort buffer 中进行排序，然后再通过主键回到原表查询需要的字段。

如果 MySQL 排序内存 sort_buffer 配置的比较小并且没有条件继续增加了，可以适当把 max_length_for_sort_data 配置小点，让优化器选择使用双路排序算法，可以在sort_buffer 中一次排序更 多的行，只是需要再根据主键回到原表取数据。
如果 MySQL 排序内存有条件可以配置比较大，可以适当增大 max_length_for_sort_data 的值，让优化器 优先选择全字段排序(单路排序)，把需要的字段放到 sort_buffer 中，这样排序后就会直接从内存里返回查询结果了。

所以，MySQL通过 max_length_for_sort_data 这个参数来控制排序，在不同场景使用不同的排序模式， 从而提升排序效率。
注意，如果全部使用sort_buffer内存排序一般情况下效率会高于磁盘文件排序，但不能因为这个就随便增 大sort_buffer(1M)，mysql很多参数设置都是做过优化的，不要轻易调整。

五、索引设计原则与实战

设计原则：

1、代码先行，索引后上
不知大家一般是怎么给数据表建立索引的，是建完表马上就建立索引吗？ 这其实是不对的，一般应该等到主体业务功能开发完毕，把涉及到该表相关sql都要拿出来分析之后再建立索引。
2、联合索引尽量覆盖条件
比如可以设计一个或者两三个联合索引(尽量少建单值索引)，让每一个联合索引都尽量去包含sql语句里的 where、order by、group by的字段，还要确保这些联合索引的字段顺序尽量满足sql查询的最左前缀原则。
3、不要在小基数字段上建立索引
索引基数是指这个字段在表里总共有多少个不同的值，比如一张表总共100万行记录，其中有个性别字段， 其值不是男就是女，那么该字段的基数就是2。 如果对这种小基数字段建立索引的话，还不如全表扫描了，因为你的索引树里就包含男和女两种值，根本没 法进行快速的二分查找，那用索引就没有太大的意义了。 一般建立索引，尽量使用那些基数比较大的字段，就是值比较多的字段，那么才能发挥出B+树快速二分查 找的优势来。
4、长字符串我们可以采用前缀索引
尽量对字段类型较小的列设计索引，比如说什么tinyint之类的，因为字段类型较小的话，占用磁盘空间也会 比较小，此时你在搜索的时候性能也会比较好一点。 当然，这个所谓的字段类型小一点的列，也不是绝对的，很多时候你就是要针对varchar(255)这种字段建立 索引，哪怕多占用一些磁盘空间也是有必要的。 对于这种varchar(255)的大字段可能会比较占用磁盘空间，可以稍微优化下，比如针对这个字段的前20个 字符建立索引，就是说，对这个字段里的每个值的前20个字符放在索引树里，类似于 KEY index(name(20),age,position)。 此时你在where条件里搜索的时候，如果是根据name字段来搜索，那么此时就会先到索引树里根据name 字段的前20个字符去搜索，定位到之后前20个字符的前缀匹配的部分数据之后，再回到聚簇索引提取出来 完整的name字段值进行比对。
但是假如你要是order by name，那么此时你的name因为在索引树里仅仅包含了前20个字符，所以这个排 序是没法用上索引的， group by也是同理。所以这里大家要对前缀索引有一个了解。
5、where与order by冲突时优先where
在where和order by出现索引设计冲突时，到底是针对where去设计索引，还是针对order by设计索引？到底是让where去用上索引，还是让order by用上索引?
一般这种时候往往都是让where条件去使用索引来快速筛选出来一部分指定的数据，接着再进行排序。 因为大多数情况基于索引进行where筛选往往可以最快速度筛选出你要的少部分数据，然后做排序的成本可能会小很多。
6、基于慢sql查询做优化 可以根据监控后台的一些慢sql，针对这些慢sql查询做特定的索引优化。
设置某一个值，比如 10s，mysql 会统计你的 sql 查询时间，超过 10s 的会将 sql 语句放入文件中，让我们自己去分析（开启会影响性能，我们可以搞一个从库去，不需要在主库上开启 ）
http://note.youdao.com/noteshare？id=c71f1e66b7f91dab989a9d3a7c8ceb8e&sub=0B91DF863FB846AA9A1CDDF431402C7B

实战

以社交场景APP来举例，我们一般会去搜索一些好友，这里面就涉及到对用户信息的筛选，这里肯定就是对 用户user表搜索了，这个表一般来说数据量会比较大，我们先不考虑分库分表的情况，比如，我们一般会筛 选地区(省市)，性别，年龄，身高，爱好之类的，有的APP可能用户还有评分，比如用户的受欢迎程度评 分，我们可能还会根据评分来排序等等。

对于后台程序来说除了过滤用户的各种条件，还需要分页之类的处理，可能会生成类似sql语句执行：
select xx from user where xx=xx and xx=xx order by xx limit xx,xx
对于这种情况如何合理设计索引了，比如用户可能经常会根据省市优先筛选同城的用户，还有根据性别去筛选，那我们是否应该设计一个联合索引 (province,city,sex) 了？这些字段好像基数都不大，其实是应该的，因为这些字段查询太频繁了。
假设又有用户根据年龄范围去筛选了，比如 where province=xx and city=xx and age>=xx and age<=xx，我们尝试着把age字段加入联合索引 (province,city,sex,age)，注意，一般这种范围查找的条件都要放在最后，之前讲过联合索引范围之后条件的是不能用索引的，但是对于当前这种情况依然用不到age这个索引字段，因为用户没有筛选sex字段，那怎么优化了？其实我们可以这么来优化下sql的写法：where province=xx and city=xx and sex in (‘female’,‘male’) and age>=xx and age<=xx
对于爱好之类的字段也可以类似sex字段处理，所以可以把爱好字段也加入索引 (province,city,sex,hobby,age)
假设可能还有一个筛选条件，比如要筛选最近一周登录过的用户，一般大家肯定希望跟活跃用户交友了，这样能尽快收到反馈，对应后台sql可能是这样：
where province=xx and city=xx and sex in (‘female’,‘male’) and age>=xx and age<=xx and latest_login_time>= xx
那我们是否能把 latest_login_time 字段也加入索引了？比如 (province,city,sex,hobby,age,latest_login_time) ，显然是不行的，那怎么来优化这种情况了？其实我们可以试着再设计一个字段is_login_in_latest_7_days，用户如果一周内有登录值就为1，否则为0，那么我们就可以把索引设计成 (province,city,sex,hobby,is_login_in_latest_7_days,age) 来满足上面那种场景了！
一般来说，通过这么一个多字段的索引是能够过滤掉绝大部分数据的，就保留小部分数据下来基于磁盘文件进行order by语句的排序，最后基于limit进行分页，那么一般性能还是比较高的。
不过有时可能用户会这么来查询，就查下受欢迎度较高的女性，比如sql：where sex = ‘female’ order by score limit xx,xx，那么上面那个索引是很难用上的，不能把太多的字段以及太多的值都用 in 语句拼接到sql里的，那怎么办了？其实我们可以再设计一个辅助的联合索引，比如 (sex,score)，这样就能满足查询要求了。
以上就是给大家讲的一些索引设计的思路了，核心思想就是，尽量利用一两个复杂的多字段联合索引，抗下你80%以上的查询，然后用一两个辅助索引尽量抗下剩余的一些非典型查询，保证这种大数据量表的查询尽可能多的都能充分利用索引，这样就能保证你的查询速度和性能了！