MySQL索引特性

我将MySQL索引分为理论和实践两大部分。

理论部分：

一.什么是索引？

MySQL的服务器，本质是在内存中的，所有的数据库的CURD操作，全都是在内存中进行的，所以索引也是如此。索引的作用是提高查找的效率。

对于我们所学到的算法，有提高算法效率的因素：

1. 组织数据的方式
2. 算法本身

组织数据的方式，比如链表的结构，比较适合：增加，删除，修改，但是不适合排序；顺序表的结构比较适合数据的排序，但是不适合数据的删除；或者哈希等等。

而对于索引，实际上就是将组织数据的方式，即数据结构给改变了，将其进行重构了，那搜索的效率自然也就变了，这就叫做结构决定算法。

索引的本质：特定的数据结构导致搜索效率的改变。

二.索引的概念

• 数据库表中存储的数据都是以记录为单位的，如果在查询数据时直接一条条遍历表中的数据记录，那么查询的时间复杂度将会是O(N)。
• 索引的价值在于提高海量数据的检索速度，只要执行了正确的创建索引的操作，查询速度就可能提高成百上千倍。当一张表创建索引后，在数据库底层就会为表中的数据记录构建特定的数据结构，后续在查询表中数据时就能通过查询该数据结构快速定位到目标数据。
• 索引虽然提高了数据的查询速度，但在一定程度上也会降低数据增删改的效率，因为这时在对表中的数据进行增删改操作时，除了需要进行对应的增删改操作之外，可能还需要对底层建立的数据结构进行调整维护。

常见索引分为：

• 主键索引(primary key)
• 唯一索引(unique)
• 普通索引(index)
• 全文索引(fulltext)–解决中子文索引问题。

索引的价值

使用如下SQL创建一个海量数据表：

上述SQL中创建了一个名为index_demon的数据库，在该数据库中创建了一个名为EMP的员工表，并向表当中插入了八百万条记录。

将上述SQL保存到文件中，然后在MySQL中使用source命令依次执行文件中的SQL即可。如下：（需要等很长时间，预计18min左右，因为数据多）

image-20230801151539550

SQL执行完毕后查看数据库就能看到一个名为bit_index的数据库。如下：

image-20230801153434687

进入该数据库，在数据库中可以看到一个名为EMP的员工表。如下：

image-20230801153642650

由于EMP表中有八百万条记录，因此在查看EMP表中的数据时可以带上limit子句。如下：

image-20230801153844509

通过desc命令可以看到，目前EMP员工表中没有建立任何索引。如下：

image-20230801153921811

查询EMP表中指定工号的员工信息，可以看到每次查询过程都需要花费8秒左右。如下：

image-20230801154139866

当我们给员工表中的工号建立索引后，数据库底层就会为员工表中的数据记录构建特定的数据结构，需要注意的是，由于当前员工表中的数据量较大，因此建立索引时也需要花费较长时间。如下：

image-20230801154311387

这时再查询EMP表中指定工号的员工信息，可以看到几乎检测不到查询时耗费的时间。如下：

image-20230801154402070

根本原因就是，给员工工号创建索引后再根据员工工号来查询数据，这时就能够直接通过底层建立的数据结构来快速定位到目标数据，从而提高数据的检索速度，这就是索引的价值。

三.认识磁盘

• MySQL给用户提供存储服务，存储的数据在磁盘这个外设当中。
• 磁盘是计算机中的一个机械设备，相比于计算机的其他电子元件，磁盘的效率是比较低的。
• 而如何提高效率是MySQL的一个重要话题，因此我们有必要了解一下磁盘的相关内容。

1. 磁盘的结构

磁盘的整体结构如下：

image-20230801155545118

部件说明：

• 永磁铁： 机械硬盘的存储方式与磁带比较类似，磁体具有记忆的功能，永磁铁是为了保证磁性的稳定。
• 音圈马达： 硬盘读取数据的关键部位，主要作用是将存储在磁盘上的信息转换为电信号向外传输。
• 主轴： 保证电机稳定的转动，磁盘转动才能读出数据。
• 空气滤波片： 过滤空气硬盘透气孔中进入的空气，保证硬盘内部清洁，同时还可以防止硬盘内部的零件氧化，确保硬盘安全使用。
• 磁盘： 硬盘一般都是铝合金制作的，主要是用来存储文件的。
• 磁头： 用来读取盘片上的信息。
• 串行接口： 用来连接电脑与硬盘的接口，起到传输的作用。

磁盘中的一个盘片

一个磁盘由多个盘片叠加而成，盘片的表面涂有磁性物质，这些磁性物质就是用来记录二进制数据的，因为盘片的正反两面都可涂上磁性物质，因此一个盘片有两个盘面。

磁盘中的一个盘片如下：

image-20230801155838415

部分说明：

• 磁道： 磁盘表面被分为许多同心圆，每个同心圆称为一个磁道，每个磁道都有一个编号，最外面的是0磁道。
• 扇区： 每个磁道被划分成若干个扇区，每个扇区的存储容量为512字节，每个扇区都有一个编号。

说明一下：

• 由于每个扇区的存储容量相同，因此最内侧磁道上的扇区数据密度最大，而最外侧磁道上的扇区数据密度最小。
• 近三十年来，扇区大小一直是512字节，但最近几年正在迁移到更大、更高效的4096字节扇区，通常称为4K扇区。
• 数据库文件就是保存在磁盘中的一个个扇区中的，因此找到一个文件本质就是，在磁盘上找到保存该文件的所有扇区。

扇区的定位方式

• 一个磁盘由多个盘片叠加而成，每个盘片有两个盘面，所有盘面中半径相同的同心磁道构成一个柱面。
• 每个盘面都有一个对应的磁头，每个磁头都有一个编号，所有的磁头都是连在同一个磁臂上的。

示意图如下：

​

image-20230801162450975

定位扇区时采用CHS寻址方式：

• 磁头（Heads）： 每个盘面都有一个对应的磁头，因此确定了磁头也就确定了数据在哪一个盘面。
• 柱面（Cylinder）： 所有盘面中半径相同的同心磁道构成柱面，因此在确定了数据在哪一个盘面的基础上，再确定柱面也就确定了数据在该盘面上的哪一个磁道。
• 扇区（Sector）： 每个磁道被划分成若干个扇区，因此在确定了数据在哪一个磁道的基础上，再确定扇区也就确定了数据在该磁道上的哪个扇区。

简单来说，CHS寻址方式就是先通过H确定数据所在的盘面，再通过C确定数据所在的磁道，最后通过S定位到目标扇区。

说明一下：

• CHS寻址方式是磁盘定位扇区的方式，但实际CHS寻址方式对磁盘以外的设备来说没什么作用，因此系统软件在定位磁盘上的数据时采用的是LBA（Logical Block Address，逻辑区块地址）。
• LBA是描述计算机存储设备上数据所在区块的通用机制，LBA和CHS之间可以通过计算公式进行相互转换，LBA存在的意义就是对底层逻辑器件进行虚拟化，让系统软件可以不用关心底层硬件具体的寻址方式，而实际底层硬件采用的还是CHS寻址方式。

操作系统与磁盘交互的基本单位

操作系统与磁盘进行IO交互的基本单位是4KB，而不是扇区的大小512字节，原因如下：

• 物理内存实际是被划分成一个个4KB大小的页框的，磁盘上的数据也会被划分成一个个4KB大小的页帧，因此操作系统与磁盘以4KB为单位进行IO交互，就能提高数据加载和保存的效率。
• 操作系统与磁盘进行IO交互时，如果直接以扇区的大小作为IO的基本单位，那么这时系统的IO代码和硬件就是强相关的，将来当硬件的扇区大小发生变化时就需要对应修改操作系统的IO代码。
• 此外，以扇区的大小作为IO的基本单位太小了，这就意味着读取同样的数据内容，需要进行更多次的磁盘访问，而磁盘的效率是比较低的，这样IO效率就降低了。

因此操作系统与磁盘以4KB作为IO交互的基本单位，一方面是为了提高IO效率，另一方面是为了实现硬件和系统的解耦。

2. 磁盘的随机访问（Random Access）与连续访问（Sequential Access）

随机访问与连续访问

• 随机访问： 本次IO所给出的扇区地址与上次IO给出的扇区地址不连续，磁头在两次IO操作之间需要做比较大的移动动作才能找到目标扇区进行IO。
• 连续访问： 本次IO所给出的扇区地址与上次IO给出的扇区地址是连续的，磁头很快就能找到目标扇区进行IO。

需要注意的是，尽管两次IO是在同一时刻发出的，但如果它们请求的扇区地址相差很大，那也只能称为随机访问，因为连续访问中的连续指的是访问的扇区地址的连续，而不是访问时间的连续，由于连续访问不需要过多的定位，因此效率比较高。

四.MySQL与磁盘交互的基本单位

MySQL作为一款应用软件，可以想象成是一种特殊的文件系统，它有着更高频的IO场景，因此为了提高基本的IO效率，MySQL与磁盘交互的基本单位是16KB，这个基本数据单元在MySQL这里也叫做Page。

通过show命令查看系统中的全局变量，可以看到InnoDB存储引擎交互的基本单位是16KB。如下：

image-20230801182320253

说明一下： 本篇博客中没有做特殊说明的地方，都是以InnoDB存储引擎为例进行讲解的。

Buffer Pool

• 在MySQL中进行的各种CRUD操作时，都需要先通过计算找到对应的操作位置，只要涉及计算就需要CPU参与，而冯诺依曼体系决定了CPU只能和内存打交道，因此为了便于CPU参与，就需要先将数据加载到内存中。
• 所以在特定的时间内，MySQL中的数据一定是同时存在于磁盘和内存中的，当操作完内存数据后，再以特定的刷新策略将内存中的数据刷新到磁盘当中，这时MySQL和磁盘进行数据交互的基本单位就是Page。
• 为了更好的支持上述操作，MySQL服务器在启动的时候会预先申请一块内存空间来进行各种缓存，这块空间叫做Buffer Pool，后续磁盘中加载的数据就会保存在Buffer Pool中，刷新数据时也就是将Buffer Pool中的数据刷新到磁盘。

所谓的操作系统和磁盘交互的基本单位是4KB，就是指内核缓冲区与磁盘之间是以4KB为单位进行交互的。而MySQL的Buffer Pool和磁盘实际并不是直接交互的，因此所谓的MySQL与磁盘交互的基本单位是16KB，指的是MySQL的Buffer Pool与内核缓冲区之间是以16KB为单位进行交互的。只不过在说的时候更关注的是MySQL和磁盘之间的关系，所以直接说的是MySQL与磁盘交互的基本单位是16KB，相当于忽略了中间的内核缓冲区。

示意图如下：

image-20230801183402495

五.索引的理解

1. 主键索引现象

首先，建立一张测试表

image-20230801190152455

将其插入一定的数据：

image-20230801192820646

我们向一个具有主键的表中，乱序插入数据，发现数据会自动排序。

根本原因就是，因为我们创建表时设置了主键，即便向表中插入数据时是乱序插入的，MySQL底层也会自动按照主键对插入的数据进行排序。

为什么MySQL与磁盘交互的基本单位是Page？

MySQL与磁盘进行交互时为什么不是按需交互，而是以Page为基本单位进行交互的呢？

• 当我们查询表中的某一条记录时，如果MySQL只从磁盘中将这一条记录加载到内存当中，那么当我们继续查询表的其他记录时，MySQL就一定需要再次与磁盘进行IO交互。
• 而如果当我们查询表中的某一条记录时，MySQL直接将这条记录所在的Page都加载到内存当中，那么当我们继续查询表的其他记录时，MySQL很可能就不再需要与磁盘进行IO交互了，因为这条记录很可能也在被加载进来的Page当中，这时直接在内存中进行查询即可，通过以Page为单位进行交互从而减少了IO的次数。
• 当然，我们不能保证用户下一次要访问的数据一定就在本次加载进来的Page当中，但是根据统计学原理，当一个数据正在被访问时，那么下一次有很大可能会访问其周围的数据（局部性原理），因此我们有较大概率保证用户下一次要访问的数据和本次访问的数据在同一个Page当中，如果局部性原理没有起作用，那就再把对应的Page加载到内存当中即可。

总结：MySQL与磁盘进行交互时以Page为基本单位，可以减少与磁盘IO交互的次数，进而提高IO的效率。

2. 推导主键结构的构建

单个Page

• MySQL中要管理很多数据文件，在运行期间一定有大量的Page需要被换入换出，因此MySQL一定需要将内存中大量的Page管理起来。
• MySQL将内存中的每一个Page都用一个结构体描述起来，然后再将各个结构体以双链表的形式组织起来，因此一个Page结构体内部既包含数据字段，也包含属性字段。
• 此外，为了方便后续数据的插入和删除，每个Page结构体内部存储的数据记录会以单链表的形式组织起来，并且各个记录之间会按照主键进行排序。

假设上述测试表中的记录都在同一个Page当中，那么该Page的结构大致如下：

image-20230802150612330

说明一下：

• 每个Page结构体内部的数据会按照主键进行排序，目的是为了优化数据查询的效率，因为单链表在查找的时候是顺序查找的，有序就意味着在查找的过程中有机会提前结束查询过程。
• 这也就是前面所说的，只要设置了主键，即便向表中插入的数据是乱序的，MySQL底层也会自动按照主键对插入的数据进行排序，因此查询得到的数据是按照主键进行有序排序的。

单个Page内创建页内目录

• Page结构体内部存储的数据记录是以单链表的形式组织起来的，当页内部的数据量增多时，本质在页内部进行的还是线性遍历，效率低下。
• 这时可以在Page结构体内部引入页内目录，将Page结构体内部存储的数据记录按照主键划分为若干区域，页内目录中就存储着这若干区域的最小键值。
• 在Page结构体内部引入页内目录后，在页内部查询数据时就可以先通过页内目录找到目标数据所在区域的起始记录，然后再从该记录开始向后遍历找到目标记录。

比如在之前的Page内部引入页内目录后的结构大致如下：

image-20230802150612330

说明一下：

• 在每个Page页内目录，目的是加速在单个Page内部数据的查询。这个页内目录也是保存在Page内部的，故这样就减少了Page对有效数据的存储，所以在Page中添加页内目录是一种空间换时间的做法。
• 每个Page结构体内部的数据会按照主键进行排序，其实就是为了引入页内目录，因为只有数据按照主键排序后引入页内目录才有意义，就像书中每一页都是按照页码进行排序的一样，如果一本书的页码是乱序的，那么它的目录根本就没有意义。

多个Page

• 随着数据量不断增大，单个Page中无法存下所有数据，这时就需要用多个Page来存储数据。
• 这时在查询数据时就需要，先遍历Page双链表确定目标数据在哪一个Page，然后再在该Page内部找到目标数据。

多个Page的示意图如下：

image-20230802152120927

Page之上创建页目录

• 虽然在单个Page内部能够通过页内目录来快速定位数据，但在遍历Page双链表寻找目标Page时本质进行的还是线性遍历。
• 这时可以给各个Page结构体也建立页目录，页目录中的每个目录项都指向一个Page，而这个目录项存放的就是其指向的Page中存放的最小数据的键值。
• 在给各个Page结构体建立页目录后，在查询数据时就可以先通过遍历页目录找到目标数据所在的Page，然后再在该Page内部找到目标数据。

image-20230802153022453

说明一下：

• 这里的页目录与之前的页内目录是不同的，此页目录管理的是一个个Page，而页内目录管理的是一天条数据。此外，页内目录与其管理的多条记录是保存在同一个Page中的，而页目录是重新申请的一个Page结构体来保存的。
• 随着数据量不断增大，
• Page变得越来越多，这时一个页目录无法管理所有的Page，这时就需要更多个的页目录。这些页目录也是一个个的Page结构体，只不过这些Page结构体中存放的不是数据记录，而是各个Page的目录信息。但是在MySQL看来，无论Page当中存储的是什么数据，都应该被管理起来，因此这些Page页目录也需要用双链表连接起来。

页目录之上再创建页目录

• 就算给各个Page结构体也建立了页目录，但随着数据量不断增大，页目录的数量也会越来越多，这时在遍历页目录寻找目标Page时本质进行的还是线性遍历。
• 类似的，我们可以不断在页目录之上再创建页目录，最终就一定能够得到一个入口页目录，这时在查询数据时就可以从入口页目录开始不断查询页目录，最终找到目标数据所在的Page，然后再在该Page内部找到目标数据。

最终构建出来的结构模型如下：

image-20230802152710334

说明一下：

• 最终构建出来的实际就是一棵B+树，这棵B+树就是InnoDB的索引结构，其中每一层Page的作用就是加速它的下一层的查找效率。
• 如果我们创建表时设置了主键，那么MySQL在底层就会自动将这张表中的的数据以B+树的形式组织起来，保存在Buffer Pool当中，当我们查询数据时就可以通过查询这棵B+树来提高查询效率。
• MySQL中可能同时有大量的表正在被处理，因此Buffer Pool中可能会存在多个索引结构，也就是同时存在多个B+树结构，当我们查询表时访问的就是这张表对应的B+树结构。

B+树中的Page结点是否需要全量加入到Buffer Pool中？

• 当对MySQL中的某张表进行增删查改操作时，不需要将其对应B+树的所有结点全量加入到Buffer Pool中，甚至在刚开始时只需要将B+树的根结点加入到Buffer Pool中。
• 当后续访问表中的数据时，再将该数据对应路径上的结点加入到Buffer Pool中即可，对于其他不需要的结点根本不用加入到Buffer Pool中，这一点和操作系统中的页表是很像的。
• 此外，在刷新数据时也不需要将B+树中所有的结点都进行刷新，在Page结构体中有一个标记位用来标记当前Page是否被修改过，如果被修改过则说明这是一个脏数据，在刷新数据时只有脏数据才需要被刷新到磁盘上。
• 由于B+树中的结点都是16KB大小的Page，因此无论是刷新数据到磁盘函数从磁盘加载数据到Buffer Pool，都是以Page为单位进行的，这也就是所谓的MySQL与磁盘交互的基本单位是Page。

如果把这棵B+树逆时针旋转90度，就会发现这其实就是操作系统中的页表结构，本质操作系统中的页表也是B+树结构。如下：

image-20230802153545073

以32位平台为例，页表将一个虚拟地址转换成物理地址的过程如下：

1. 选择虚拟地址的前10个比特位在页目录当中进行查找，找到对应的页表。
2. 再继续选择虚拟地址后续的10个比特位在对应的页表当中进行查找，找到物理内存中对应页框的起始地址。
3. 最后选择虚拟地址中剩下的12个比特位作为偏移量，从对应页框的起始地址处向后进行偏移，最终得到的就是转换后的物理地址。

说明一下：

• 12个比特位有212种取值，而212字节对应就是4KB，所以物理内存中一个页框的大小就是4KB，这也就是为什么操作系统与磁盘交互的基本单位就是4KB的原因。
• 此外，页表中的各个B+树结点也不需要全量加入到内存中，而只需要加入访问到的结点即可，所以页表占用的内存大小实际是可控的，这也就是为什么二级页表可行的原因。

3. 索引结构可以采取哪些数据结构

除了InnoDB存储引擎所采用的B+树结构，索引结构还可以采用哪些数据结构呢？

• 链表：查找时是线性遍历，效率太低。
• 普通二叉搜索树：可能退化成线性结构，这时查找还是线性遍历。
• AVL树和红黑树：虽然保证了二叉树是绝对或近似平衡的，不会退化成线性结构，但AVL树和红黑树都是二叉树结构，这就意味着树的层高会比较高，而查询数据时都是从根结点开始向下进行查找的，这也就意味着在查询过程中需要遍历更多结点，如果这些结点还没有被加载到Buffer Pool中，这时就需要进行更多次的IO操作，所以最终没有选择其作为索引结构。
• 哈希表：官方的索引实现方式中MySQL是支持HASH的，只不过InnoDB和MyISAM存储引擎并不支持。哈希表的优点就是它的时间复杂度是 O ( 1 )的，但哈希表也有一个缺点就是不利于进行数据的范围查找。

下面是几个常见的存储引擎，与其所支持的索引类型：

B树 VS B+树

B+树是B树的一种变形结构，那为什么我们没有采用普通的B树作为索引结构呢？

• 首先，普通B树中的所有结点中都同时包括索引信息和数据信息，由于一个Page的大小是固定的，因此非叶子结点中如果包含了数据信息，那么这些结点中能够存储的索引信息一定会变少，这时这棵树形结构一定会变得更高更瘦，当查询数据时就可能需要与磁盘进行更多次的IO操作。
• 其次，普通B树中的各个叶子结点之间没有连接起来，这将不利于进行数据的范围查找，而B+树的各个叶子结点之间是连接起来的，当我们进行范围查找时，直接先找到第一个数据然后继续向后遍历找到之后的数据即可，因此将各个叶子结点连接起来更有利于进行数据的范围查找。

4. 聚簇索引和非聚簇索引

MyISAM 存储引擎-主键索引

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

image-20230802164031794

• MyISAM 最大的特点是，将索引Page和数据Page分离，也就是叶子节点没有数据，只有对应数据的地址。
• 此结构将B+树的搜索结构与具体数据进行分离，B+树的叶子结点记录实际数据的地址，我们将这种索引称为非聚簇索引。

因此，什么是非聚簇索引？

非聚簇索引： 我们把这种将数据和索引结构分离的索引称之为非聚簇索引。

与此同时，我们也就能推导出什么是聚簇索引：

聚簇索引： 我们把将数据和索引结构放在一起的索引称之为聚簇索引。

如上，聚簇索引与非聚簇索引的区别就是B+树的叶子结点存储的是数据还是数据的地址。如果是数据的地址，该结构就是非聚簇索引；如果是数据本身，该结构就是聚簇索引。

证明一下：

image-20230802165626745

innodb的存储引擎，将索引和数据都放在了xxx.idb文件中，这就是聚簇索引。

image-20230802170056808

myisam的存储引擎，将索引和数据分离，数据存在xxx.MYD文件，索引存在xxx.MYI文件，这就是非聚簇索引。

• 由于MySQL默认的就是innodb存储结构，故默认是聚簇索引。
• 当然， MySQL 除了默认会建立主键索引外，我们用户也有可能建立按照其他列信息建立的索引，一般这种索引可以叫做辅助（普通）索引。

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

image-20230802170533877

说明一下：

• InnoDB存储引擎的普通索引的B+树叶子结点中没有保存整条数据记录，是为了节省空间，因为同一张表可能会创建多个普通索引，每个普通索引的B+树中都保存一份数据会造成数据冗余，所以通过回表查询主键索引对应的B+来获取整个数据记录，该做法本质一种以时间换取空间的做法。
• 当根据普通索引查询数据时，其实也不一定需要进行回表查询，因为有可能我们要查询的就是这条记录对应的主键值，因此查询完普通索引对应B+树后即可完成查询。
• 采用InnoDB存储引擎建立的每张表都会有一个主键，就算用户没有设置，InnoDB也会自动帮你创建一个不可见的主键，因为完整数据记录只会存储在主键索引对应的B+树中的，因此采用InnoDB存储引擎建立的表必须有主键。

实践部分：

六.索引操作

一个索引代表一个B+树，即索引的名字，实际上也是对应的B+树的名字。

1. 查询索引

我们上面创建的test1和test2两张表，因为创建的主键，都有对应的索引，通过以下语句，就能查询索引：

方式一： show keys from 表名

image-20230802191057238

解释一下：

• Key_name：索引的名字。示例中的名字为primary。
• Column_name：表示索引所在的字段。示例中的字段为id。
• Index_type：表示索引的结构。示例中的索引结构为BTREE，这个名称代表的就是B+树，而不是B树。

方式二：show index from 表名;

image-20230802191416400

方式三：desc 表名; —信息比较简略

image-20230802191513203

下面索引的创建，我们都演示方式三，因为方式三才是创建表之后才添加索引的，具有普适性。

2. 主键索引的创建

方式一：在创建表的时候，直接在字段名后指定 primary key

方式二：在创建表的最后，指定某列或某几列为主键索引

方式二与方式一本质上没有区别。

方式三：创建表之后，再指定字段添加索引

image-20230802192355708

主键索引的特点：

• 一个表中，最多有一个主键索引。当然也可以使用复合索引。
• 主键索引的效率高（主键不可重复，所以在创建B+时，搜索效率一定快）。
• 创建主键索引的列，它的值不能为null，且不能重复。
• 主键索引的列基本上是int。

3. 唯一索引的创建

在添加唯一键约束时，其默认也会创建B+树，构成索引。

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

方式二：创建表时，在表的后面指定某列或某几列为unique

方式三：创建表之后，再指定字段添加索引

这就是给name增加了对应的索引。如果此时再将id设置成primary key，那么该表就有两棵B+树。

image-20230802193831360

唯一索引的特点：

• 一个表中，可以有多个唯一索引
• 查询效率高
• 如果在某一列建立唯一索引，必须保证这列不能有重复数据
• 如果一个唯一索引上指定not null，等价于主键索引

4. 普通索引的创建

方式一：在表的定义最后，指定某列为索引

方式二：创建完表以后指定某列为普通索引（最常用）

方式三：创建一个索引名为myindex的索引

image-20230802201535769

普通索引的特点：

• 一个表中可以有多个普通索引，普通索引在实际开发中用的比较多。
• 如果某列需要创建索引，但是该列有重复的值，那么我们就应该使用普通索引。

5. 全文索引的创建（了解）

全文索引比较常见的案例就是对文章中的词进行搜索，比如下面创建一个文章表，表当中包含文章的id、文章名称、文章内容，并在创建表的最后通过fulltext给title和body列创建全文索引。如下：

image-20230803150544303

下面向表当中插入一些测试数据。如下：

image-20230803150648402

如果要查询哪些文章中包含database关键字，我们可以通过模糊匹配进行查找。如下：

image-20230803150742613

但实际这种查找方式并没有用到全文索引，在SQL语句前面加上explain，可以看到key对应的值为NULL，表示这条SQL在执行过程中没有用到任何索引。如下：

image-20230803150855549

如果要通过全文索引来查询，需要使用match against进行搜索。如下：

image-20230803150958584

在这条SQL语句前面加上explain，可以看到key对应的值为title，表示这条SQL在执行过程中用到了索引名为title的索引。如下：

image-20230803151055294

说明一下：

• MyISAM存储引擎是支持全文索引的，而InnoDB存储引擎是在5.6以后才开始支持全文索引的。
• 同时使用title和body建立全文索引时，相当于建立了一个复合索引，默认会选择fulltext中的第一个列名作为这个复合索引的索引名，所以这里explain中key对应的索引名为title。
• 由于是title和body共同建立的全文索引，所以如果文章当中没有出现关键字，但文章名称中出现了关键字则也会被筛选出来（当前示例没有体现出来）。

6. 删除索引

删除索引实际上就和我们之前修改表结构一样。

删除主键索引

image-20230802191957331

其他索引的删除：

索引名就是show keys from 表名中的 Key_name对应的字段。

image-20230802194153241

此时就不存在name对应的索引了。删除主键索引，也可以以其他索引的方式删除，这种删除更具有普适性。

说明一下：

• 一个表只有一个主键索引，所以在删除主键索引的时候不用指明索引名，而一个表中可能有多个非主键索引，所以在删除非主键索引时需要指明索引名。

7.多列索引的创建

对于如下表，只有id存在索引：

image-20230803142252310

若想同时将另外两个字段添加索引，就需要在index()的括号中同时添加两个字段：

image-20230803142636153

这样，除了主键索引，也出现了另外两个索引。但是需要注意的是，不是又构建了两棵B+树，而是name和email同时看成一个整体作为一个索引，即这两个的数据是作用在一棵B+树上的，从key_name中的名字也可以看出，他们的B+树都是name，也就是以第一个字段的名字作为Key值。所以，此表目前仅仅存在两棵B+树。

如果要删掉name索引结构，这两个的索引同时都会消失，这就是因为同属于一个B+树。

image-20230803143219207

当然，多列索引的创建不止一种方式，因为单列索引的创建不止一种方式。

我们将多列索引称之为复合索引，而复合索引实际上就是普通索引，只不过是将多个字段放在一起作为索引。

七.索引创建原则

• 比较频繁作为查询条件的字段应该创建索引。
• 唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件。
• 更新非常频繁的字段不适合作创建索引。
• 不会出现在where子句中的字段不该创建索引。

总结：创建索引的目的，就是为了提高查询的效率。