【读书笔记】MySQL实战45讲——索引

课程来自极客时间《MySQL实战45讲》

一、何为索引

索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。

1、索引的常见模型

实现索引的方式有多种，常见、简单的数据结构有以下三种

1.1、哈希表

哈希表是一种以键-值（key-value）存储数据的结构，我们只要输入待查找的值即key，就可以找到其对应的值即Value

哈希的思路是，把值放在数组里，用一个哈希函数把key换算成一个确定的位置，然后把value放在数组的这个位置。

若有多个key值经过哈希函数运算后得到同一个值，会使用拉链法，也就是在数组上拉出链表

因为数组不是有序的，所以查找范围的数据需要全表查询，所以哈希表这种结构适用于只有等值查询的场景

1.2、有序数组

而有序数组在等值查询和范围查询场景中的性能就都非常优秀

但是，在需要更新数据的时候就麻烦了，你往中间插入一个记录就必须得挪动后面所有的记录，成本太高。

所以，有序数组索引只适用于静态存储引擎

1.3、搜索树

树可以有二叉，也可以有多叉，一棵二叉搜索树如下所示，查询速度为O(log(N))

为什么大多数数据库存储不使用二叉树？

因为索引不止存在内存中，还要写到磁盘上。

举个例子

一棵100万节点的平衡二叉树，树高20。一次查询可能需要访问20个数据块。在机械硬盘时代，从磁盘随机读一个数据块需要10 ms左右的寻址时间。也就是说，对于一个100万行的表，如果使用二叉树来存储，单独访问一个行可能需要20个10 ms的时间，这个查询可真够慢的

所以为了尽量少地读磁盘，必须让查询过程访问尽量少的数据块，这就应该使用N叉树，N取决于数据块的大小

二、InnoDB 的索引模型

在InnoDB中，表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为索引组织表

InnoDB使用了B+树索引模型，所以数据都是存储在B+树中的

所以得出结论，每一个索引在InnoDB里面对应一棵B+树

1、索引类型

索引类型分为主键索引和非主键索引

主键索引的叶子节点存的是整行数据。在InnoDB里，主键索引也被称为聚簇索引

非主键索引的叶子节点内容是主键的值。在InnoDB里，非主键索引也被称为二级索引

1.1、基于主键索引和普通索引的查询有什么区别？

• 如果语句是select * from T where ID=500，即主键查询方式，则只需要搜索ID这棵B+树；
• 如果语句是select * from T where k=5，即普通索引查询方式，则需要先搜索k索引树，得到ID的值为500，再到ID索引树搜索一次。这个过程称为回表。

基于非主键索引的查询需要多扫描一棵索引树

1.2、使用自增主键的好处？

由于普通索引的叶子节点就是主键的值，主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小

1.3、有没有不使用自增主键，用业务字段做主键的场景？

有些业务的场景需求是这样的：

1. 只有一个索引
2. 该索引必须是唯一索引

由于没有其他索引，所以也就不用考虑其他索引的叶子节点大小的问题

此时可以直接将这个索引设置为主键，直接使用主键查询

2、索引维护

B+树为了维护索引有序性，在插入新值的时候需要做必要的维护

以上面这个图为例，如果插入新的行ID值为700，则只需要在R5的记录后面插入一个新记录。如果新插入的ID值为400，就相对麻烦了，需要逻辑上挪动后面的数据，空出位置。

而更糟的情况是，如果R5所在的数据页已经满了，根据B+树的算法，这时候需要申请一个新的数据页，然后挪动部分数据过去。这个过程称为页分裂。

除了性能外，页分裂操作还影响数据页的利用率。原本放在一个页的数据，现在分到两个页中，整体空间利用率降低大约50%。

当然有分裂就有合并。当相邻两个页由于删除了数据，利用率很低之后，会将数据页做合并。合并的过程，可以认为是分裂过程的逆过程。

三、覆盖索引

如果在查询中，我们要的查询结果与索引上的查询结果一致，那么索引就可以说是覆盖了查询需求，这就叫做覆盖索引。

由于覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段。

四、最左前缀原则

B+树这种索引结构，可以利用索引的“最左前缀”，来定位记录

举个例子，这时有联合索引(name,age)，索引项是按照索引定义里面出现的字段顺序排序的

如果你要查的是所有名字第一个字是“张”的人，你的SQL语句的条件是"where name like ‘张%’"。这时，你也能够用上这个索引，查找到第一个符合条件的记录是ID3，然后向后遍历，直到不满足条件为止

不只是索引的全部定义，只要满足最左前缀，就可以利用索引来加速检索。这个最左前缀可以是联合索引的最左N个字段，也可以是字符串索引的最左M个字符

在建立联合索引的时候，如何安排索引内的字段顺序？
第一原则是，如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的

五、索引下推

最左前缀可以用于在索引中定位记录，不符合最左前缀的部分会有两种情况

1. MySQL 5.6之前，只能一个个回表。到主键索引上找出数据行，再对比字段值
2. MySQL 5.6 引入的索引下推优化（index condition pushdown)， 可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数

举个例子
现在联合索引为(name,age)，有一个需求：检索出表中“名字第一个字是张，而且年龄是10岁的所有男孩”。

根据前缀索引规则，这个语句在搜索索引树的时候，只能用 “张”，找到第一个满足条件的记录，根据上面两种情况有以下两种情况

无索引下推

有索引下推，会对年龄先进行判断和过滤

六、问题

1、问题1

如果你要重建索引 k，你的两个SQL语句可以这么写：

alter table T drop index k;
alter table T add index(k);

如果你要重建主键索引，也可以这么写：

alter table T drop primary key;
alter table T add primary key(id);

问题是，对于上面这两个重建索引的作法，说出你的理解。如果有不合适的，为什么，更好的方法是什么？

答案：为什么要重建索引？
索引可能因为删除，或者页分裂等原因，导致数据页有空洞，重建索引的过程会创建一个新的索引，把数据按顺序插入，这样页面的利用率最高，也就是索引更紧凑、更省空间。

对上面问题进行回答
重建索引k的做法是合理的，可以达到省空间的目的。

但是，重建主键的过程不合理。不论是删除主键还是创建主键，都会将整个表重建。

所以连着执行这两个语句的话，第一个语句就白做了。这两个语句，你可以用这个语句代替 ： alter table T engine=InnoDB。

2、问题2

实际上主键索引也是可以使用多个字段的。DBA小吕在入职新公司的时候，就发现自己接手维护的库里面，有这么一个表，表结构定义类似这样的：

CREATE TABLE `geek` (
  `a` int(11) NOT NULL,
  `b` int(11) NOT NULL,
  `c` int(11) NOT NULL,
  `d` int(11) NOT NULL,
  PRIMARY KEY (`a`,`b`),
  KEY `c` (`c`),
  KEY `ca` (`c`,`a`),
  KEY `cb` (`c`,`b`)
) ENGINE=InnoDB;

公司的同事告诉他说，由于历史原因，这个表需要a、b做联合主键，这个小吕理解了。

但是，学过本章内容的小吕又纳闷了，既然主键包含了a、b这两个字段，那意味着单独在字段c上创建一个索引，就已经包含了三个字段了呀，为什么要创建“ca”“cb”这两个索引？

同事告诉他，是因为他们的业务里面有这样的两种语句：

select * from geek where c=N order by a limit 1;
select * from geek where c=N order by b limit 1;

我给你的问题是，这位同事的解释对吗，为了这两个查询模式，这两个索引是否都是必须的？为什么呢？

答案：ca可以去掉，cb需要保留。

表记录
–a–|–b–|–c–|–d–
1 2 3 d
1 3 2 d
1 4 3 d
2 1 3 d
2 2 2 d
2 3 4 d
主键 a，b的聚簇索引组织顺序相当于 order by a,b ，也就是先按a排序，再按b排序，c无序。

索引 ca 的组织是先按c排序，再按a排序，同时记录主键
–c–|–a–|–主键部分b-- （注意，这里不是ab，而是只有b）
2 1 3
2 2 2
3 1 2
3 1 4
3 2 1
4 2 3
这个跟索引c的数据是一模一样的。

索引 cb 的组织是先按c排序，在按b排序，同时记录主键
–c–|–b–|–主键部分a-- （同上）
2 2 2
2 3 1
3 1 2
3 2 1
3 4 1
4 3 2