MySQL索引详解

前言

因为MySQL的索引中最重要的数据结构就是B+树，因此前面咱们先大概讲讲B+树的原理

B+ Tree 原理

1. 数据结构

B Tree 指的是 Balance Tree，也就是平衡树。平衡树是一颗查找树，而且全部叶子节点位于同一层。

B+ Tree 是基于 B Tree 和叶子节点顺序访问指针进行实现，它具备 B Tree 的平衡性，而且经过顺序访问指针来提升区间查询的性能。

在 B+ Tree 中，一个节点中的 key 从左到右非递减排列，若是某个指针的左右相邻 key 分别是 keyi 和 keyi+1，且不为 null，则该指针指向节点的全部 key 大于等于 keyi 且小于等于 keyi+1。

2. 操做

进行查找操做时，首先在根节点进行二分查找，找到一个 key 所在的指针，而后递归地在指针所指向的节点进行查找。直到查找到叶子节点，而后在叶子节点上进行二分查找，找出 key 所对应的 data。

插入删除操做会破坏平衡树的平衡性，所以在插入删除操做以后，须要对树进行一个分裂、合并、旋转等操做来维护平衡性。

3. 与红黑树的比较

红黑树等平衡树也能够用来实现索引，可是文件系统及数据库系统广泛采用 B+ Tree 做为索引结构，主要有如下两个缘由：

（一）更少的查找次数

平衡树查找操做的时间复杂度等于树高 h，而树高大体为 O(h)=O(logdN)，其中 d 为每一个节点的出度。

红黑树的出度为 2，而 B+ Tree 的出度通常都很是大，因此红黑树的树高 h 很明显比 B+ Tree 大很是多，查找的次数也就更多。

（二）利用磁盘预读特性

        为了减小磁盘 I/O，磁盘每每不是严格按需读取，而是每次都会预读。预读过程当中，磁盘进行顺序读取，顺序读取不须要进行磁盘寻道，而且只须要很短的旋转时间，速度会很是快。

        操做系统通常将内存和磁盘分割成固态大小的块，每一块称为一页，内存与磁盘以页为单位交换数据。数据库系统将索引的一个节点的大小设置为页的大小，使得一次 I/O 就能彻底载入一个节点。而且能够利用预读特性，相邻的节点也可以被预先载入。

MySQL 索引

索引是在存储引擎层实现的，而不是在服务器层实现的，因此不一样存储引擎具备不一样的索引类型和实现。

1. B+Tree 索引

是大多数 MySQL 存储引擎的默认索引类型。

由于再也不须要进行全表扫描，只须要对树进行搜索便可，因此查找速度快不少。

除了用于查找，还能够用于排序和分组。

能够指定多个列做为索引列，多个索引列共同组成键。

适用于全键值、键值范围和键前缀查找，其中键前缀查找只适用于最左前缀查找。若是不是按照索引列的顺序进行查找，则没法使用索引。

InnoDB 的 B+Tree 索引分为主索引和辅助索引。主索引的叶子节点 data 域记录着完整的数据记录，这种索引方式被称为聚簇索引。由于没法把数据行存放在两个不一样的地方，因此一个表只能有一个聚簇索引。

辅助索引的叶子节点的 data 域记录着主键的值，所以在使用辅助索引进行查找时，须要先查找到主键值，而后再到主索引中进行查找。

2. 哈希索引

哈希索引能以 O(1) 时间进行查找，可是失去了有序性：

• 没法用于排序与分组；
• 只支持精确查找，没法用于部分查找和范围查找。

InnoDB 存储引擎有一个特殊的功能叫“自适应哈希索引”，当某个索引值被使用的很是频繁时，会在 B+Tree 索引之上再建立一个哈希索引，这样就让 B+Tree 索引具备哈希索引的一些优势，好比快速的哈希查找。

3. 全文索引

MyISAM 存储引擎支持全文索引，用于查找文本中的关键词，而不是直接比较是否相等。

查找条件使用 MATCH AGAINST，而不是普通的 WHERE。

全文索引使用倒排索引实现，它记录着关键词到其所在文档的映射。

InnoDB 存储引擎在 MySQL 5.6.4 版本中也开始支持全文索引。

4. 空间数据索引

MyISAM 存储引擎支持空间数据索引（R-Tree），能够用于地理数据存储。空间数据索引会从全部维度来索引数据，能够有效地使用任意维度来进行组合查询。

必须使用 GIS 相关的函数来维护数据。

索引优化

1. 独立的列

在进行查询时，索引列不能是表达式的一部分，也不能是函数的参数，不然没法使用索引。

例以下面的查询不能使用 actor_id 列的索引：

SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;复制代码

2. 多列索引

在须要使用多个列做为条件进行查询时，使用多列索引比使用多个单列索引性能更好。例以下面的语句中，最好把 actor_id 和 film_id 设置为多列索引。

SELECT film_id, actor_ id FROM sakila.film_actor WHERE actor_id = 1 AND film_id = 1;复制代码

3. 索引列的顺序

让选择性最强的索引列放在前面。

索引的选择性是指：不重复的索引值和记录总数的比值。最大值为 1，此时每一个记录都有惟一的索引与其对应。选择性越高，查询效率也越高。

例以下面显示的结果中 customer_id 的选择性比 staff_id 更高，所以最好把 customer_id 列放在多列索引的前面。

SELECT COUNT(DISTINCT staff_id)/COUNT(*) AS staff_id_selectivity,
COUNT(DISTINCT customer_id)/COUNT(*) AS customer_id_selectivity,
COUNT(*)
FROM payment;复制代码

staff_id_selectivity: 0.0001
customer_id_selectivity: 0.0373
               COUNT(*): 16049复制代码

4. 前缀索引

对于 BLOB、TEXT 和 VARCHAR 类型的列，必须使用前缀索引，只索引开始的部分字符。

对于前缀长度的选取须要根据索引选择性来肯定。

5. 覆盖索引

索引包含全部须要查询的字段的值。

具备如下优势：

• 索引一般远小于数据行的大小，只读取索引能大大减小数据访问量。
• 一些存储引擎（例如 MyISAM）在内存中只缓存索引，而数据依赖于操做系统来缓存。所以，只访问索引能够不使用系统调用（一般比较费时）。
• 对于 InnoDB 引擎，若辅助索引可以覆盖查询，则无需访问主索引。

6. 最左前缀原则

顾名思义是最左优先，以最左边的为起点任何连续的索引都能匹配上

联合索引本质：

当建立(a,b,c)联合索引时，至关于建立了(a)单列索引，(a,b)联合索引以及(a,b,c)联合索引

想要索引生效的话,只能使用 a和a,b和a,b,c三种组合。

索引的优势

• 大大减小了服务器须要扫描的数据行数。
• 帮助服务器避免进行排序和分组，以及避免建立临时表（B+Tree 索引是有序的，能够用于 ORDER BY 和 GROUP BY 操做。临时表主要是在排序和分组过程当中建立，由于不须要排序和分组，也就不须要建立临时表）。
• 将随机 I/O 变为顺序 I/O（B+Tree 索引是有序的，会将相邻的数据都存储在一块儿）。

索引的使用条件

• 对于很是小的表、大部分状况下简单的全表扫描比创建索引更高效；
• 对于中到大型的表，索引就很是有效；
• 可是对于特大型的表，创建和维护索引的代价将会随之增加。这种状况下，须要用到一种技术能够直接区分出须要查询的一组数据，而不是一条记录一条记录地匹配，例如可使用分区技术。

小结

索引是MySQL中一个很重要的功能，平常开发中若是能用好索引，能大幅度提升SQL语句的执行性能，因此了解其中的原理也是十分必要的。

文章大部分参考自

github.com/CyC2018/CS-…