MySQL学习笔记——索引

索引

0.前言

本文是跟着网课学习的时候随手记录的一篇关于MySQL索引的学习笔记

1.索引概述

1.1.索引介绍

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

1.2.索引演示

那么，索引到底是怎么提升查询性能的呢？我们先举一个简单的例子进行说明：

假如现在有如下这么一张数据表，我们需要查询表中年龄(age)为45的字段

🔑id	name	age
1	金庸	36
2	张无忌	22
3	杨逍	33
4	韦一笑	48
5	常遇春	53
6	小昭	19
7	灭绝	45
8	周芷若	17
9	丁敏君	23
10	赵敏	20

在无索引情况下，就需要从第一行开始扫描，一直扫描到最后一行，我们称之为 全表扫描，性能很低。

[!NOTE]

不是扫描到id为7，第一次找到age为45的字段就结束扫描了，因为你不能保证在这之后就没有age同样也为45的人了，所以无论如何都要进行全表扫描，这样的话效率是极低的

那么这个时候，如果加上索引，会怎么样呢？这里我们以二叉树为例：

不同于之前，加上了二叉树为索引会把数据库表中的每个字段都对应到一个二叉树里面

而根据二叉树的生成规则，小的放左边，大的放右边，我们从上往下搜索。比如我们要找age为45的字段，从父节点36开始找，45比38大，往右边走找到了48，发现45比48小，再往左边走，只用了三步就找到了

[!CAUTION]

实际上MySQL的存储引擎InnoDB并不是以二叉树为索引的，这里只是举个例子

1.3.索引优缺点

• 优点
  1. 提高数据检索的效率，降低数据库 的IO成本
  2. 通过索引列对数据进行排序，降低 数据排序的成本，降低CPU的消 耗
• 缺点
  1. 索引是需要占用空间的
  2. 索引大大提高了查询效率，同时却也降低更新表的速度， 如对表进行增删改时，效率降低

而实际上，索引的缺点在很多时候都可以忽略，理由如下：

• 虽然索引占用内存空间，但是现在设备的存储能力都非常发达，牺牲一点空间来提升效率是非常划算的
• 一般来说，对于数据库的查询操作次数远远多于增删改的次数，因此提升查询性能是首要的

2.索引结构

2.1.结构概述

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

• B+Tree

  最常见的索引类型，大部分引擎都支持 B+ 树索引

• Hash索引

  底层数据结构是用哈希表实现的, 只有精确匹配索引列的查询才有效, 不支持范围查询

• R-tree(空间索引)

  空间索引是MyISAM引擎的一个特殊索引类型，主要用于地理空间数据类 型，通常使用较少

• Full-text(全文索引)

  是一种通过建立倒排索引,快速匹配文档的方式。类似于 Lucene,Solr,ES

我们再来看看不同的存储引擎对于索引结构的支持情况：

索引	InnoDB	MyISAM	Memory
B+Tree	支持	支持	支持
Hash	不支持	不支持	支持
R-tree	不支持	支持	不支持
Full-text	5.6版本后支持	支持	不支持

2.2.二叉树的问题

在1.2的索引演示中，产生出来的是一个很标准的二叉树结构，这是一种理想情况

但是实际应用中，往往数据库中的数据量非常的大，而且要是顺序插入数据，二叉树会退化：

这看起来就不再是一颗"树"了，而是退化成了一个单向链表了

那单向链表的查询，还是要遍历所有数据啊，相当于全表扫描，优化了个寂寞……

所以，MySQL数据存储并没有用二叉树，就是因为二叉树在一些特定情况会退化

2.3.红黑树的问题

那么，二叉树不行，红黑树总可以了吧，因为红黑树会自平衡，根本不存在退化为链表的可能

这样想没错，但是我们上面说到，实际应用中的数据量是非常庞大的，如果用红黑树来存储，会导致最终的这棵红黑树会非常非常"深"，也就是树的层数会很大，那么会导致一些查询的性能还是很低，因为得往红黑树最底下，最深处去查询

那么有没有既不会退化，大数据量情况下层数又相对浅一些的方案呢？

2.4.B-Tree

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

[!TIP]

树的度数是指每一个节点的子节点个数

比如我要寻找56这个数字，从最上面的根节点开始，56在30和62之间所以走第三个指针(从左往右第三个)，然后在第二层的第三个叶子节点就找到了56，其它查询都是同理

B-Tree的生成特点：

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

B-Tree具体怎么演变的，不做详细介绍，需要的话可以看下方视频👇

B-Tree详解

2.5.B+Tree

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

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

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

• 所有的数据都会出现在叶子节点
• 叶子节点形成一个单向链表
• 非叶子节点仅仅起到索引数据作用，具体的数据都是在叶子节点存放的

上述我们所看到的结构是标准的B+Tree的数据结构，接下来，我们再来看看MySQL中优化之后的 B+Tree。 MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上，增加一个指向相邻叶子节点 的链表指针，就形成了带有顺序指针的B+Tree，提高区间访问的性能，利于排序

2.6.Hash

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

比如说，根据"金庸"这个名字计算出来的hash值是005，那么就存储到序号为005对应的槽位上

然后005槽位就会存储这个字段的信息，以及这个字段对应的hash值

但是，不同的名字计算出来的hash值是有可能一样的，这种现象叫做哈西碰撞

比如说，根据"杨逍"这个名字计算出来的哈希值也是005，那么杨逍就会和原先存储在005的金庸一起形成一个链表，挂在金庸的后面，依次类推，如下图：

这种存储方式有点像Java里面的HashMap

Hash索引的特点：

• Hash索引只能用于对等比较(=，in)，不支持范围查询（between，>，< ，...）
• 无法利用索引完成排序操作
• 查询效率高，通常(不存在hash冲突的情况)只需要一次检索就可以了，效率通常要高于B+tree索引

2.7.MySQL为什么用B+Tree

• 相对于二叉树和红黑树，层级更少，搜索效率高，而且不会发生退化
• 对于B-tree，有如下的原因：
  1. 范围查询效率高： B+树相比于B树，其非叶子节点只包含键值信息，而不包含数据记录的具体地址。这使得 B+ 树能更好地支持范围查询和顺序遍历操作
  2. 顺序访问效率高： B+树的叶子节点形成一个有序链表，对于需要顺序访问的场景（如范围查询、按主键的顺序查询等），可以通过遍历这个有序链表来实现高效的查询和扫描操作
  3. 更适合磁盘存储： 在数据库系统中，数据通常是存储在磁盘上的，而 B+树的结构特性使得单次 I/O 操作能够读取更多的数据页，这有助于减少磁盘 I/O 次数，提高查询性能
  4. 支持更大的索引范围： B+树相对于B树，能够支持更大的索引范围，因为内部节点不存储数据，只存储键值信息，这样可以增加树的分支因子，减少树的高度，进而提高索引查询效率
• 相对Hash索引，B+tree支持范围匹配及排序操作

3.索引分类

3.1.索引分类

在MySQL数据库中，将索引的具体类型主要分为以下几类：

分类	含义	特点	关键字
主键索引	针对于表中主键创建的索引	默认自动创建, 只能 有一个	PRIMARY
唯一 索引	避免同一个表中某数据列中的值重复	可以有多个	UNIQUE
常规 索引	快速定位特定数据	可以有多个	无
全文 索引	全文索引查找的是文本中的关键词，而不是比较索引中的值	可以有多个	FULLTEXT

3.2.聚集索引和二级索引

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

分类	含意	特点
聚集索引	将数据存储与索引放到了一块，索引结构的叶子 节点保存了行数据	必须有,而且只 有一个
二级索引	将数据与索引分开存储，索引结构的叶子节点关 联的是对应的主键	可以存在多个

聚集索引的选取规则：

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

那么这俩索引到底是什么样子的呢？我们看下图：

可以很直观地看出来，聚集索引叶子节点下面直接挂了这一整行的数据

二级索引叶子节点则是字段值下面挂了这个字段所在行的主键值

那么数据库怎么根据索引来查询的呢？我们以下面这个SQL语句为例

select * from user where name = "Arm"

我们直接以二级索引为例

首先，从根节点开始遍历，根据字典排序规则，"Arm"的"A"要在"Lee"的"L"之前，所以走第一个从左往右第一条线，也就是第一个指针。然后到达叶子节点，和叶子节点第一个元素"Greek"比较，发现"Arm"排序还是在"Greek"之前，继续走叶子节点的第一个指针，然后就直接找到了"Arm"元素，并找到了"Arm"字段所在行的行主键，也就是id=10

那么这就结束了吗？我们现在只是拿到了这一行的id主键，还没有查到这一行的数据呢！然后，我们又要去聚集索引里面去查元素，按照B+树的查找规则从上往下查找，才能差找到id=10对应哪一行的数据，也就是上图的"row"

所以，为什么叫做"二级索引"呢？因为根据二级索引不能直接查到数据行，查到的只是主键，还得再查一次聚集索引

4.索引使用

4.1.索引语法

• 创建索引

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

• 查看索引

SHOW INDEX FROM table_name ;

• 删除索引

DROP INDEX index_name ON table_name ;

下面随便举一些例子来说明这几个语句是怎么用的

1. phone手机号字段的值，是非空，且唯一的，为该字段创建唯一索引

CREATE UNIQUE INDEX idx_user_phone ON tb_user(phone);

2. 为profession、age、status创建联合索引

CREATE INDEX idx_user_pro_age_sta ON tb_user(profession,age,status);

[!NOTE]

索引的创建最好满足以下命名规范：

1.对于非联合索引：idx _ 表名_ 字段名

2.对于联合索引，在上面规范的基础上用下划线链接要联合的所有字段名

4.2.SQL性能分析

为什么要分析SQL性能呢？因为，对于一个特定业务场景下的数据库，增删改查这四个主要操作对应的频率一般是不均衡的。而对于SQL优化，我们基本上只要集中精力去优化频率高的SQL即可

要想知道各个查询的频率，我们只需要输入如下命令：

-- session 是查看当前会话 ;
-- global 是查询全局数据 ;
SHOW GLOBAL STATUS LIKE 'Com_______';

上面的"Com_ _ _ _ _ _ _"实际上是七个下划线连在一起，每条下划线代表一中数据库操作

我们只需要关注增删改即可：

• Com_delete: 删除次数
• Com_insert: 插入次数
• Com_select: 查询次数
• Com_update: 更新次数

输入命令并提交之后就会展示各个操作的执行次数，就知道我们应该着重优化那种数据库操作了

清楚需要优化哪种数据库操作之后，接下来就要对SQL的执行进行监控了。我们一般需要知道一条SQL语句的执行时间，这样就知道这条SQL的执行效率了

监控SQL语句主要有如下三种方式：

• 慢查询日志

如果要开启慢查询日志，需要在MySQL的配置文件中配置如下信息：

# 开启MySQL慢日志查询开关
slow_query_log=1
# 设置慢日志的时间为2秒，SQL语句执行时间超过2秒，就会视为慢查询，记录慢查询日志
long_query_time=2

• profile详情

show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。通过have_profiling 参数，能够看到当前MySQL是否支持profile操作：

# 查询是否支持profile
SELECT @@have_profiling ;
# 开启profile
SET profiling = 1;

开启profile之后，通过如下指令查看SQL语句执行耗时：

-- 查看每一条SQL的耗时基本情况
show profiles;
-- 查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;
-- 查看指定query_id的SQL语句CPU的使用情况
show profile cpu for query query_id;

• explain

EXPLAIN或者DESC命令获取 MySQL 如何执行 SELECT 语句的信息，包括在 SELECT 语句执行 过程中表如何连接和连接的顺序。

-- 直接在select语句之前加上关键字 explain / desc
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件 ;

Explain 执行计划中各个字段的含义:

字段	含义
id	select查询的序列号，表示查询中执行select子句或者是操作表的顺序 (id相同，执行顺序从上到下；id不同，值越大，越先执行)
select_type	表示 SELECT 的类型，常见的取值有 SIMPLE（简单表，即不使用表连接 或者子查询）、PRIMARY（主查询，即外层的查询）、 UNION（UNION 中的第二个或者后面的查询语句）、 SUBQUERY（SELECT/WHERE之后包含了子查询）等
type	表示连接类型，性能由好到差的连接类型为NULL、system、const、 eq_ref、ref、range、 index、all
possible_key	显示可能应用在这张表上的索引，一个或多个
key	实际使用的索引，如果为NULL，则没有使用索引
key_len	表示索引中使用的字节数， 该值为索引字段最大可能长度，并非实际使用长 度，在不损失精确性的前提下， 长度越短越好
rows	MySQL认为必须要执行查询的行数，在innodb引擎的表中，是一个估计值， 可能并不总是准确的
filtered	表示返回结果的行数占需读取行数的百分比， filtered 的值越大越好

4.3.最左前缀法则

如果索引了多列(联合索引)，要遵循最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列

如果跳过了某一列，索引将部分失效(后面字段的索引失效)

这是什么意思呢？比如我用如下SQL语句创建一个联合索引：

CREATE INDEX idx_user_pro_age_sta ON tb_user(profession,age,status);

可以知道，从左往右的顺序依次为：1.profession 2.age 3.status

清楚这个顺序之后，我们来看下面几个查询语句：

• 根据三个字段进行查询

select * from tb_user where profession = '软件工程' and age = 31 and status = '0';

这样查询索引肯定是能正常存在的不会失效，因为没有缺少任何字段且最左边的profession存在

• 根据profession和status进行查询

select * from tb_user where profession = '软件工程' and status = '0';

这样子查询索引部分失效，因为最左边的字段profession存在但是中间跳过了字段，导致部分失效

• 根据age和status进行查询

select * from tb_user where age = 31 and status = '0';

这样索引就彻底失效了，因为最左边的profession字段没了，索引直接失效

也就是说，只要最左边的那个字段存在即可，而且和它在SQL语句中的顺序是没有关系的

4.4.范围查询

联合查询中，出现范围查询(>,<)，范围查询右侧的索引列失效

什么意思呢？还是拿上面的三个字段为例，看下面这个SQL语句：

select * from tb_user where profession = '软件工程' and age > 30 and status = '0';

因为SQL语句中出现了"age > 30"这样的大于号，会导致status，也就是age右侧的索引列失效

如果要规避这种情况，在业务允许的情况下，尽可能使用大于等于来替代大于即可

4.5.其它索引失效情况

• 在SQL中使用了函数或者一些运算，索引失效

比如我要查询手机尾号(phone字段)为15的用户信息：

select * from tb_user where substring(phone,10,2) = '15';

这里用到了一个字符串截取函数，这会导致索引失效

• 使用字符串类型字段不加引号会导致索引失效

比如我要查询手机号为17799990015的用户信息：

explain select * from tb_user where phone = '17799990015';
explain select * from tb_user where phone = 17799990015;

显然手机号在数据库中是varchar类型存储的，下面的SQL不规范，没有加单引号会导致索引失效

• 头部模糊查询

如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效

比如，我要对于profession字段进行模糊查询，看下面的三个SQL语句：

explain select * from tb_user where profession like '软件%';
explain select * from tb_user where profession like '%工程';
explain select * from tb_user where profession like '%工%';

第二句SQL和第三句SQL在头部有模糊查询的通配符，导致了索引失效

• 用or连接条件

当or连接的条件，左右两侧字段都有索引时，索引才会生效

比如，看下面这两句示例SQL：

explain select * from tb_user where id = 10 or age = 23;
explain select * from tb_user where phone = '17799990017' or age = 23;

由于age没有索引，所以即使id、phone有索引，索引也会失效。所以需要针对于age也要建立索引

• 数据分布导致索引失效

这种情况比较特殊，但是比较好理解

比如我们根据手机号字段范围查询用户数据：

select * from tb_user where phone >= '17799990005';
select * from tb_user where phone >= '17799990015';

备注：整个表的手机号字段只有17799990000-17799990023

这时候，我们发现第一句SQL用全表扫描而不用索引而第二句SQL用了索引

因为数据分布情况是：手机号字段大于等于17799990005的占据绝大多数，数据库在执行查询的时候认为，要查询绝大部分的数据了，还是走全表扫描更快一些，从而放弃索引

也就是说，在执行SQL之前，数据库并不是有索引就用，而是会评估使用索引的"性价比"

4.6.SQL提示

• use index:建议MySQL使用哪一个索引完成此次查询(仅仅是建议，mysql内部还会再次进行评估)

explain select * from tb_user use index(idx_user_pro) where profession = '软件工程';

• ignore index:忽略指定的索引

explain select * from tb_user ignore index(idx_user_pro) where profession = '软件工程';

• force index:强制使用索引

explain select * from tb_user force index(idx_user_pro) where profession = '软件工程';

4.7.索引覆盖

什么是覆盖索引呢？覆盖索引是指查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到

比如说我要查询gender、age着两个字段，那么在使用或者创建索引的时候，尽量选择包含这两个字段的索引，这样查询性能会更高

为什么用覆盖索引的查询性能会更高呢？比如我们要执行如下SQL：

selet id,name,gender from tb_user where name = 'Arm';

如上图，首先会根据name="Arm"去下面的辅助索引去查询，然后就能找到id=2，且name="Arm"的字段

但是，我们还要查询一个gender字段，可是在辅助索引里面没有这个字段啊？

这就意味着，还要拿着从辅助索引里面查出来的id=2又回到聚集索引里面去查，相当于要查两次表

如果说，创建一个同时包含了gender和name字段的索引，那么就不用进行回表查询了

4.8.前缀索引

当字段类型为字符串（varchar，text，longtext等）时，有时候需要索引很长的字符串，这会让 索引变得很大，查询时，浪费大量的磁盘IO， 影响查询效率。此时可以只将字符串的一部分前缀，建 立索引，这样可以大大节约索引空间，从而提高索引效率

例如，为tb_user表的email字段，建立长度为5的前缀索引

create index idx_email_5 on tb_user(email(5));

但是这就有一个问题，怎么取这个前缀索引的长度，才能让前缀索引的性能最大呢？

可以使用下面这个计算公式来计算前缀索引的性能：

select count(distinct email) / count(*) from tb_user ;

就是求不重复的字符串的数量和总数量的比值，如果比值是1，那么这个索引的性能就是最高的。这个比值又可以称之为——选择性

比如下面这种情况，判断给email字段的前五个字符创建前缀索引的性能如何：

select count(distinct substring(email,1,5)) / count(*) from tb_user ;

实际选择前缀索引的时候，并不是一定要用选择性为1的索引，还需要考虑这个索引的大小。如果这个前缀索引截取的字符串太长，会导致这个索引的体积很大，要将索引体积和选择性结合起来综合考虑