MySQL调优(六)-索引优化

索引基本知识

索引的优点

• 大大减少了服务器需要扫描的数据量
• 帮助服务器避免排序和临时表
• 将随机IO变成顺序IO

索引的用处

• 快速查询匹配WHERE子句的行
• 从consideration中消除行，如果可以在多索引之间进行选择，Mysql通常会使用找到最少行的索引
• 如果表具有多列索引，则优化器可以使用索引的任何最左前缀来查找行
• 当有表连接的时候，从其他表检索行数据
• 查找特定索引列的min或max值
• 如果排序或分组时在可用索引的最左前缀上完成的，则对表进行排序和分组
• 在某些情况下，可以优化查询以检索值而无需查询数据行

索引的分类

• 主键索引
• 唯一索引
• 普通索引
• 全文索引
• 组合索引

Mysql会根据唯一索引来创建索引

技术名词

• 回表：在InnoDB引擎中，叶子节点存放的时间是主键，如果WHERE子句中查询name值，那么会先拿到主键再去拿需要的数据。
• 覆盖索引：所需要的字段能够在索引找到，同时避免了回表。

select id,name ...... # 覆盖索引

• 最左匹配：创建索引时可以会有多个列组成索引，以最左边的字段开始匹配。

# idx_name_age(name,age)
select * from user where name = ? and age = ? # 使用索引
select * from user where age = ?                        # 索引失效
select * from user where age = ? and name = ? # 优化器会优化，使用索引

• 索引下推：在使用索引的情况下，如果存在某些被索引的列的判断条件时，MySQL服务器将这一部分判断条件传递给存储引擎，然后由存储引擎通过判断索引是否符合MySQL服务器传递的条件，只有当索引符合条件时才会将数据检索出来返回给MySQL服务器 。

索引下推是在非主键索引上的优化，可以有效减少回表的次数，大大提升了查询的效率。

索引采用的数据结构

• hash

InnoDB引擎不支持，在MEMORY引擎中支持
利用hash存储的话需要将所有的数据文件添加到内存，比较耗费内存空间
如果所有的查询都是等值查询，那么hash很快，但是在实际工作环境中范围查找数据更多，而不是等值查询。

• B+ tree

二叉树：可能会造成两边的脚一边高一边低，导致IO次数变多，影响数据读取的效率

二叉树

AVL树：为了保证数据的平衡(高度差不会超过1)，会做1-N次的旋转。导致插入效率很低，但是查询效率还是很高的。并且树的深度依然很深。
红黑树：AVL树的一个变种，树的深度依然会很深。
B tree：所有键值分布在整棵树中(所以Mysql一页拿到的数据非常少)，搜索有可能在非叶子节点结束，在关键字全集内做一次查找，性能逼近二分查找。根节点至少有2个子树
B+ tree：所有数据都存在叶子节点中，非叶子节点存储地址指针。

索引匹配方式

• 全值匹配：条件中和索引中的所有列进行匹配

explain select * from staffs where name = 'July' and age = '23' and pos = 'dev'

• 最左匹配：只匹配前面的几列

explain select * from staffs where name = 'July' and age = '23'
explain select * from staffs where name = 'July'

• 列前缀匹配：匹配某一列的值的开头部分

explain select * from staffs where name like 'J%'  # 使用索引
explain select * from staffs where name like '%y'  # 不使用索引

• 范围值匹配：查找某一个范围的数据

explain select * from staffs where name > 'Mary'

• 精确匹配：可以查询第一列的全部和第二列的部分

explain select * from staffs where name = 'July' and age > 25;

• 只访问索引的查询：查询的时候只需要访问索引，不需要访问数据行，本质上就是覆盖索引

explain select name,age,pos from staffs where name = 'July' and age = 25 and pos = 'dev'

哈希索引

基于哈希表的实现，只有精确匹配索引所有列的查询才有效
在mysql中，只有memory的存储引擎显示支持哈希索引
哈希索引自身只存储对应的hash值，，所以索引的结构十分紧凑，查找的速度非常快

哈希索引的限制

• 1、哈希索引只包含哈希值和行指针，而不存储字段值，索引不能使用索引中的值来避免读取行
• 2、哈希索引数据并不是按照索引值顺序存储的，所以无法进行排序
• 3、哈希索引不支持部分列匹配查找，哈希索引是使用索引列的全部内容来计算哈希值
• 4、哈希索引支持等值比较查询，也不支持任何范围查询
• 5、访问哈希索引的数据非常快，除非有很多哈希冲突，当出现哈希冲突的时候，存储引擎必须遍历链表中的所有行指针，逐行进行比较，直到找到所有符合条件的行
• 6、哈希冲突比较多的话，维护的代价也会很高

如何避免hash冲突？
1、使用优秀的hash算法
2、hash再hash (效率较低)

组合索引

当包含多个列作为索引，需要注意的是正确的顺序依赖于该索引的查询，同时需要考虑如何更好的满足排序的分组的需要

聚簇索引与非聚簇索引

聚簇索引

不是单独的索引类型，而是一种数据存储方式，指的是数据行跟相邻的键值紧凑的存储在一起

优点

• 可以把相关数据保存在一起
• 数据访问更快，因为索引和数据保存在同一个树中
• 使用覆盖索引扫描的查询可以直接使用页节点中的主键值

缺点

• 聚簇数据最大限度地提高了IO密集型应用的性能，如果数据全部在内存，聚簇索引则没什么优势
• 插入速度严重依赖于插入顺序，按照主键的顺序插入时最快的方式
• 更新聚簇索引列的代价很高，因为会强制将每个被更新的行移动到新的位置
• 基于聚簇索引的表在插入新航，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题
• 聚簇索引可能导致全表扫描变慢，尤其时行比较稀疏，或者由于页分裂导致数据存储不连续的时候

非聚簇索引

数据文件跟索引文件分开存放

覆盖索引

1、如果一个索引包含所有需要查询的字段和值，则为覆盖索引
2、不是所有类型的索引都可以称为覆盖索引，覆盖索引必须要存储索引列的值
3、不同的存储实现覆盖索引的方式不同，不是所有的引擎都支持覆盖索引，memory不支持覆盖索引

优势

• 索引条目通常远小于数据行大小，如果只需要读取索引，那么Mysql就会极大的减少数据访问量
• 因为索引时按照列值的顺序存储的，所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少的多
• 一些存储引擎，如MYISAM在内存中只有缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用，这可能会导致严重的性能问题
• 由于InnoDB的聚簇索引，覆盖索引对InnoDB表特别有用

优化小细节

• 当使用索引列进行查询的时候尽量不要使用表达式，把计算放到业务层而不是数据库

select id from user id = 4;
select id from user id+1 = 5;

• 尽量使用主键查询，而不是其他索引，因此主键查询不会触发回表查询
• 使用前缀索引
• 使用索引扫描来排序
• union all、in、or 都能够使用索引，但推荐使用in
• 范围列可以使用索引，但是范围列后面的列无法用到索引，索引最多用于一个范围列
• 强制类型转换会全表扫描
• 更新十分频繁且数据区分度不高的字段不宜建立索引
• 创建索引的列，不允许为null，可能会得到不符合预期的结果
• 当需要进行表连接的时候，最好不要超过三张表，因为需要join的字段，数据类型必须一致
• 能使用limit的时候尽量使用limit
• 单表索引建议控制在5个以内
• 单索引字段数不允许超过5个 （组合索引）
• 创建索引的时候应该避免一下错误概念

索引越多越好
过早优化，在不了解系统的情况下进行优化

索引监控

show status like handler_read%;

参数	参数解释
Handler_read_first	读取索引第一个条目的次数
Handler_read_key	通过index获取数据的次数
Handler_read_last	读取索引最后的一个条目的次数
Handler_read_next	通过索引读取下一条数据的次数
Handler_read_prev	通过索引读取上一条数据的次数
Handler_read_rnd	从固定位置读取数据的次数
Handler_read_rnd_next	从数据节点读取下一条数据的次数