MySQL索引结构（面试题）、索引分类、语法

2索引

2.1 索引概述

2.1.1 介绍

​ 索引（index）是帮助MySQL高效获取数据的数据结构(有序)。在数据之外，数据库系统还维护着满足 特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构 上实现高级查找算法，这种数据结构就是索引。

2.2 索引结构

2.2.1 概述

MySQL的索引是在存储引擎层实现的，不同的存储引擎有不同的索引结构，主要包含以下几种：

上述是MySQL中所支持的所有的索引结构，接下来，我们再来看看不同的存储引擎对于索引结构的支持 情况。

2.2.2 二叉树

假如说MySQL的索引结构采用二叉树的数据结构，比较理想的结构如下：

所以，如果选择二叉树作为索引结构，会存在以下缺点：

• 顺序插入时，会形成一个链表，查询性能大大降低。

• 大数据量情况下，层级较深，检索速度慢。

• 
  所以，在MySQL的索引结构中，并没有选择二叉树或者红黑树，而选择的是B+Tree，那么什么是B+Tree呢？在详解B+Tree之前，先来介绍一个B-Tree。

2.2.3 B-Tree

• B-Tree，B树是一种多叉路平衡查找树，相对于二叉树，B树每个节点可以有多个分支，即多叉。
• 以一颗最大度数（max-degree）为5 (5阶)的b-tree为例，那这个B树每个节点最多存储4个key，5个指针：
  
  树的度数指的是一个节点的子节点个数。

特点：

• 5阶的B树，每一个节点最多存储4个key，对应5个指针。
• 一旦节点存储的key数量到达5，就会裂变，中间元素向上分裂。
• 在B树中，非叶子节点和叶子节点都会存放数据。

2.2.4 B+Tree

B+Tree是B-Tree的变种，我们以一颗最大度数（max-degree）为4（4阶）的b+tree为例，来看一 下其结构示意图：

我们可以看到，两部分：

• 绿色框框起来的部分，是索引部分，仅仅起到索引数据的作用，不存储数据。
• 红色框框起来的部分，是数据存储部分，在其叶子节点中要存储具体的数据。

插入一组数据： 100 65 169 368 900 556 780 35 215 1200 234 888 158 90 1000 88 120 268 250 。然后观察一些数据插入过程中，节点的变化情况。

最终我们看到，B+Tree 与 B-Tree相比，主要有以下三点区别：

• 所有的数据都会出现在叶子节点。

• 叶子节点形成一个单向链表。

• 非叶子节点仅仅起到索引数据作用，具体的数据都是在叶子节点存放的。

上述我们所看到的结构是标准的B+Tree的数据结构，接下来，我们再来看看MySQL中优化之后的B+Tree。

MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上，增加一个指向相邻叶子节点 的链表指针，就形成了带有顺序指针的B+Tree，提高区间访问的性能，利于排序。

2.2.5 Hash

MySQL中除了支持B+Tree索引，还支持一种索引类型—Hash索引。

1). 结构 哈希索引就是采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储在hash表中。

2). 特点

• A. Hash索引只能用于对等比较(=，in)，不支持范围查询（between，>，< ，…）

• B. 无法利用索引完成排序操作

• C. 查询效率高，通常(不存在hash冲突的情况)只需要一次检索就可以了，效率通常要高于B+tree索 引

  3). 存储引擎支持 在MySQL中，支持hash索引的是Memory存储引擎。 而InnoDB中具有自适应hash功能，hash索引是InnoDB存储引擎根据B+Tree索引在指定条件下自动构建的。

面试题：

思考题： 为什么InnoDB存储引擎选择使用B+tree索引结构?

一 .相对于二叉树，层级更少，搜索效率高；

二.

• 对于B-tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低；
• Ｂ＋树中间节点没有卫星数据（索引元素所指向的数据记录），只有索引。这就意味着同样的大小的磁盘页可以容纳更多节点元素，在相同的数据量下，Ｂ＋树更加“矮胖”，ＩＯ操作更少。
• 其次，因为卫星数据的不同，导致查询过程也不同；Ｂ树的查找只需找到匹配元素即可，最好情况下查找到根节点，最坏情况下查找到叶子结点，所说性能很不稳定，而Ｂ＋树每次必须查找到叶子结点，性能稳定
• 在范围查询方面，B+树的优势更加明显
  B树的范围查找需要不断依赖中序遍历。首先二分查找到范围下限，在不断通过中序遍历，直到查找到范围的上限即可。整个过程比较耗时。
  而B+树的范围查找则简单了许多。首先通过二分查找，找到范围下限，然后同过叶子结点的链表顺序遍历，直至找到上限即可，整个过程简单许多，效率也比较高。

C. 相对Hash索引，B+tree支持范围匹配及排序操作；

总结：B+树相比B树的优势：
　　1.单一节点存储更多的元素，使得查询的IO次数更少；
　　2.所有查询都要查找到叶子节点，查询性能稳定；
　　3.所有叶子节点形成有序链表，便于范围查询。

2.3 索引分类

2.3.1 索引分类

​ 在MySQL数据库，将索引的具体类型主要分为以下几类：主键索引、唯一索引、常规索引、全文索引。

2.3.2 聚集索引&二级索引

而在在InnoDB存储引擎中，根据索引的存储形式，又可以分为以下两种：

下面 有例子解释

• 聚集索引的叶子节点下挂的是这一行的数据 。
• 二级索引的叶子节点下挂的是该字段值对应的主键值。

接下来，我们来分析一下，当我们执行如下的SQL语句时，具体的查找过程是什么样子的。

具体过程如下:

• ①. 由于是根据name字段进行查询，所以先根据name='Arm’到name字段的二级索引中进行匹配查 找。但是在二级索引中只能查找到 Arm 对应的主键值 10。
• ②. 由于查询返回的数据是*，所以此时，还需要根据主键值10，到聚集索引中查找10对应的记录，最 终找到10对应的行row。
• ③. 最终拿到这一行的数据，直接返回即可。

回表查询： 这种先到二级索引中查找数据，找到主键值，然后再到聚集索引中根据主键值，获取 数据的方式，就称之为回表查询。

聚集索引选取规则:

• 如果存在主键，主键索引就是聚集索引。
• 如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引。
• 如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引。

思考题：

以下两条SQL语句，那个执行效率高? 为什么?
A. select * from user where id = 10 ;
B. select * from user where name = ‘Arm’ ;
备注: id为主键，name字段创建的有索引；
解答：

A 语句的执行性能要高于B 语句。 因为A语句直接走聚集索引，直接返回数据。 而B语句需要先查询name字段的二级索引，然 后再查询聚集索引，也就是需要进行回表查询

思考题：

InnoDB主键索引的B+tree高度为多高呢?

假设:一行数据大小为1k，一页中就可以存储16行这样的数据。（页的大小16K）
InnoDB的指针占用6个字节的空间，主键即使为bigint，占用字节数为8。

高度为2时：设key为n ，则指针数量为n+1。
n * 8 + (n + 1) * 6 = 16*1024 , 算出n约为 1170 
每一个指针指向一个页，一个页是16K，一行数据大小为1k。
 1171* 16 = 18736. 指针×行数 = 记录。
 也就是说，如果树的高度为2，则可以存储 18000 多条记录。
 
高度为3时：第一层根节点只有一个节点，一个节点由上面算出来是1171个指针，在第2层每一个节点那就也有1171个指针。
所以此时指针共有 1711*1171 再×16就是行数据。
 1171 * 1171 * 16 = 21939856
 也就是说，如果树的高度为3，则可以存储 2200w 左右的记录

2.4 索引语法

1). 创建索引

CREATE [ UNIQUE | FULLTEXT ] INDEX index_name ON table_name ( 
index_col_name,... ) ;

2). 查看索引

SHOW INDEX FROM table_name ;

3). 删除索引
 DROP INDEX index_name ON table_name ;

案例演示:

先来创建一张表 tb_user，并且查询测试数据。

A. name字段为姓名字段，该字段的值可能会重复，为该字段创建索引。
CREATE INDEX idx_user_name ON tb_user(name);

B. phone手机号字段的值，是非空，且唯一的，为该字段创建唯一索引。
CREATE UNIQUE INDEX idx_user_phone ON tb_user(phone);

C. 为profession、age、status创建联合索引。
CREATE INDEX idx_user_pro_age_sta ON tb_user(profession,age,status);

D. 为email建立合适的索引来提升查询效率。
CREATE INDEX idx_email ON tb_user(email);