【MySQL】索引

一、认识索引

MySQL 服务器本质是在内存中的，所以的数据库的 CURD 操作也是都在内存中进行的，索引也是如此；索引是为了提供搜索效率，他本质是一个数据结构；

mysql> select * from EMP where empno=998877;

+--------+--------+----------+------+---------------------+---------+--------+--------+

| empno | ename | job | mgr | hiredate | sal | comm | deptno |

+--------+--------+----------+------+---------------------+---------+--------+--------+

| 998877 | mhaFbo | SALESMAN | 0001 | 2026-03-09 00:00:00 | 2000.00 | 400.00 | 159 |

+--------+--------+----------+------+---------------------+---------+--------+--------+

1 row in set (7.31 sec) 没加索引之前

mysql> alter table EMP add index(empno); 加索引中

Query OK, 0 rows affected (12.93 sec)

Records: 0 Duplicates: 0 Warnings: 0

mysql> select * from EMP where empno=998877; 加完索引之后

+--------+--------+----------+------+---------------------+---------+--------+--------+

| empno | ename | job | mgr | hiredate | sal | comm | deptno |

+--------+--------+----------+------+---------------------+---------+--------+--------+

| 998877 | mhaFbo | SALESMAN | 0001 | 2026-03-09 00:00:00 | 2000.00 | 400.00 | 159 |

+--------+--------+----------+------+---------------------+---------+--------+--------+

1 row in set (0.00 sec)

二、MySQL 与磁盘交互的基本单位

首先MySQL是不会直接和磁盘打交道的，根据冯诺依曼体系 OS 是所有硬件的管理者，OS 和磁盘进行交互，因为在MySQL中所有的表或者数据库都是文件，所以在 MySQL 读数据的时候是以 read 系统调用来读取，读取单位是 16kb ，也就是说 OS 文件缓冲区里面的数据大小必须是 16kb，也就意味着 OS 至少要读取磁盘 4 次，一次是 4kb，当MySQL写数据是也是以 16kb 来写的，此时 OS 的文件缓冲区里的数据大小是 16kb ，OS 使用 fsync 来一次刷新到磁盘上：

根据局部性原理：磁盘读取数据的大小为 4k ，但是 OS 要 4kb ，大大提高了读取的效率，降低磁头摆动的时间，而 MySQL 要 16kb 的数据更加提高读取数据的效率；

证明MySQL是以 16kb 为单位的：

16384 字节 / 1024 字节 = 16 kb；

MySQL中的数据文件，是以page为单位保存在磁盘当中的。

MySQL的CURD操作，都需要通过计算，找到对应的插入位置，或者找到对应要修改或者查询的数据。

而只要涉及计算，就需要CPU参与，而为了便于CPU参与，一定要能够先将数据移动到内存当中。

所以在特定时间内，数据一定是磁盘中有，内存中也有。后续操作完内存数据之后，以特定的刷新策略，刷新到磁盘。而这时，就涉及到磁盘和内存的数据交互，也就是I0了。而此时10的基本单位就是Page。

为了更好的进行上面的操作，MysQL服务器在内存中运行的时候，在服务器内部，就申请了被称为Buffer Pool 的的大内存空间，来进行各种缓存。其实就是很大的内存空间，来和磁盘数据进行10交互。

为何更高的效率，一定要尽可能的减少系统和磁盘IO的次数

为什么插入数据是时候是无序的但是查找的时候是有序的？是谁让他有序的？为什么这么干？

在回答这个问题之前，我们先重谈 page :

如何理解 MySQL 中的 page 的概念：

因为MySQL的 buffer pool 的默认大小是 128 M ，所以这就意味着MySQL中有大量的 page （要插入的 page 、需要刷新的 page等），这也就意味着 MySQL 要将多个同时存在的 page 管理起来，怎么管理？先描述，再组织；使用结构体来描述，使用数据结构来组织（链表）；所以不要单纯的将 page 认为是一个内存块，page 内部也必须写入对应的管理信息；

注意：这个有序是建立在这个表有主键；

回答上面的那个问题：是 mysqld 做的，为了提高查询的效率；

三、理解单个 page

MySQL中要管理很多数据表文件，而要管理好这些文件，就需要先描述，在组织，我们目前可以简单理解成一个个独立文件是有一个或者多个Page构成的。

在MySQL中，每个 page 的大小都是 16kb，使用 prev和next 构成双向链表；

因为有主键的问题，MysQL会默认按照主键给我们的数据进行排序，从上面的Page内数据记录可以看出，数据是有序且彼此关联的。

页内存储数据的结构也是链表结构，而链表插入和删除块，查找慢；假设上图的 page 内的数据记录都10w条，查询第 1w 条，此时就是线性查询，效率太慢，为了提高查询效率，引入页目录的概念：跟我们书本的目录一样；

这样我们只要遍历目录就得快速找到目标数据；

结论：让插入的数据有序是为了形成页目录，进而提高查询的效率；

但是，如果数据记录大于 16kb（实际上存储数据一定是小于 16kb，原因：1.一部分空间用来当作目录，2.一部分空间存储 page 属性），那么MySQL要开辟新的 page 来存储数据，这里就要提到多个 page；

四、理解多个 page

这样，我们就可以通过多个Page遍历，Page内部通过目录来快速定位数据。可是，貌似这样也有效率问题，在Page之间，也是需要MysQL遍历的，遍历意味着依旧需要进行大量的IO，将下一个Page加载到内存，进行线性检测。这样就显得我们之前的Page内部的目录，有点杯水车薪了。

解决方案：给 page 带上目录；

使用一个目录项来指向某一页，而这个目录项存放的就是将要指向的页中存放的最小数据的键值。和页内目录不同的地方在于，这种目录管理的级别是页，而页内目录管理的级别是行。其中，每个目录项的构成是：键值+指针。图中没有画全。

注意：目录项的 page 不存储数据记录，这就意味着目录项可以存储非常多的页的键值和指针；

存在一个目录页来管理页目录，目录页中的数据存放的就是指向的那一页中最小的数据。有数据，就可通过比较，找到该访问那个Page，进而通过指针，找到下一个Page。

其实目录页的本质也是页，普通页中存的数据是用户数据，而目录页中存的数据是普通页的地址。

注意：根据目录查询数据，本质就是淘汰机制；

如果插入的数据太多，非常多，导致底层的 page 太多，此时如果一个目录页存储的普通页的键值和地址空间不够，此时 MySQL 就会开辟新的目录页；如果开辟的目录页太多，此时我们查找一条数据，MySQL 就要遍历线性的目录页（是链表结构，但是不是双向链表，而是单向链表，只有底层的 page 是双向链表），进而降低查询效率，怎么办？解决方案：再引入目录；

结论：

1）根据上面的这张图，我们可以看出这颗树是 B+ 树结构（本质上是多叉树）

2）这棵树只有叶子节点有数据，非叶子节点只有目录项；

3）非叶子节点不存储数据，存储目录项，所以目录页进行可以管理更多的叶子：page；

4）单单上面上面的 3 层结构，就能管理非常大的数据，所以这颗树一定是一个矮胖型的树，所以路上节点是非常少的，进而找到目标的数据只需要更少的 page ，导致 IO 次数减少，提高效率；

5）每个节点都有目录项，大大提高了搜索效率；

6）使用 B+ 似的结构称为：MySQL innode db 下的索引结构；

7）一般我们建表插入数据的时候，表没有主键，也是上面图中的结构，因为有默认的主键（这个主键不和我们插入的信息无关）；

问题：为什么叶子节点全部用链表连接起来？

答：1.这是 MySQL 选择了 B+ 树的原因，这时 B+ 树的特点；2.我们比较希望进行范围查找；

Page分为目录页和数据页。目录页只放各个下级Page的最小键值。查找的时候，自定向下找，只需要加载部分目录页到内存，即可完成算法的整个查找过程，大大减少了10次数；

为什么 MySQL 选择 B+ 树，不选择链表、二叉树、红黑树、AVL 树数据结构？

答：首先链表会导致线性遍历，进而导致 IO 的次数上升，降低效率；其次，无论是二叉树、还是红黑、AVL 树都是瘦高的现状，进而导致路上的节点增加，进而增加 IO 次数，降低效率；

为什么 MySQL 不选择 B 树？

答：B+树节点不存储data，这样一个节点就可以存储更多的key。可以使得树更矮，所以IO操作次数更少。叶子节点相连，更便于进行范围查找；

五、聚簇索引 VS 非聚簇索引

MyISAM存储引擎-主键索引MyISAM引擎同样使用B+树作为索引结果，叶节点的data域存放的是数据记录的地址。下图为MyISAM表的主索引，co11为主键。

其中，MyISAM最大的特点是，将索引Page和数据Page分离，也就是叶子节点没有数据，只有对应数据的地址。相较于InnoDB索引，InnoDB是将索引和数据放在一起的。

其中，MyISAM这种用户数据与索引数据分离的索引方案，叫做非聚簇索引；

其中，InnoDB这种用户数据与索引数据在一起索引方案，叫做聚簇索引

当然，MysQL除了默认会建立主键索引外，我们用户也有可能建立按照其他列信息建立的索引，一般这种索引可以叫做辅助（普通）索引。

对于MyISAM，建立辅助（普通）索引和主键索引没有差别，无非就是主键不能重复，而非主键可重复。下图就是基于MyISAM的Co12建立的索引，和主键索引没有差别；

同样，InnoDB除了主键索引，用户也会建立辅助（普通）索引，我们以上表中的Co13建立对应的辅助索引如下图：

可以看到，InnoDB的非主键索引中叶子节点并没有数据，而只有对应记录的key值。

所以通过辅助（普通）索引，找到目标记录，需要两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。这种过程，就叫做回表查询

为何InnoDB针对这种辅助（普通）索引的场景，不给叶子节点也附上数据呢？原因就是太浪费空间了。

六、索引操作

1）主键索引的创建

-- 在创建表的时候，直接在字段名后指定 primary key

create table user1(id int primary key, name varchar(30));
-- 在创建表的最后，指定某列或某几列为主键索引

create table user2(id int, name varchar(30), primary key(id))；
create table user3(id int, name varchar(30)); -- 创建表以后再添加主键

alter table user3 add primary key(id);

主键索引的特点：

一个表中，最多有一个主键索引，当然可以使符合主键

主键索引的效率高(主键不可重复)

创建主键索引的列，它的值不能为null，且不能重复

主键索引的列基本上是int

2）唯一索引的创建

-- 在表定义时，在某列后直接指定unique唯一属性。

create table user4(id int primary key, name varchar(30) unique);
-- 创建表时，在表的后面指定某列或某几列为unique

create table user5(id int primary key, name varchar(30), unique(name));
create table user6(id int primary key, name varchar(30)）；

alter table user6 add unique(name);

唯一索引的特点：

一个表中，可以有多个唯一索引

查询效率高

如果在某一列建立唯一索引，必须保证这列不能有重复数据

如果一个唯一索引上指定not null，等价于主键索引