【MySQL精通之路】InnoDB(6)-磁盘结构(2)-索引

主博客：

【MySQL精通之路】InnoDB(6)-磁盘上的InnoDB结构-CSDN博客

【MySQL精通之路】磁盘上的InnoDB结构-表空间-CSDN博客

1.聚集索引和二级索引

1.1 Innodb 如何建立聚集索引

1.2 聚集索引如何加快查询速度

1.3 二级索引与聚集索引的关系

2.InnoDB索引的物理结构

3.排序索引构建

3.1 为未来指数增长预留B树页面空间

3.2 排序索引构建和全文索引支持

3.3 排序索引构建和压缩表

3.4 排序索引生成和 Redolog

3.5 排序索引构建和优化器统计信息

4.InnoDB全文索引

1.聚集索引和二级索引

每个InnoDB表都有一个特殊的索引，称为聚集索引，用于存储行数据。

博主PS：注意一张表只有一个聚簇索引！心里念三遍，对了，聚集，聚簇都是一个意思

通常，聚集索引与主键同义。为了从查询、插入和其他数据库操作中获得最佳性能，了解InnoDB如何使用聚集索引来优化公共查找和DML操作是很重要的。

1.1 Innodb 如何建立聚集索引

当您在表上定义PRIMARY KEY时，InnoDB会将其用作聚集索引。应该为每个表定义一个主键。如果没有逻辑唯一和非null列或列集（官网原文是：set of columns）可以作为主键，请添加一个自动递增列。自动递增列值是唯一的，并且在插入新行时自动添加。

博主PS：

这里意思是如果你没有业务逻辑上的主键，那么也尽量使用一个自增id作为主键！┓( ´∀` )┏

如果没有为表定义PRIMARY KEY

InnoDB将使用第一个非空定义，且建立了唯一（UNIQUE）索引作为聚集索引，其中所有键列都定义为not null

如果表没有PRIMARY KEY或合适的UNIQUE索引，InnoDB会在包含行ID值的自动生成的列上生成一个名为GEN_CLUST_INDEX的隐藏聚集索引。行按InnoDB分配的行ID排序。行ID是一个6字节字段，随着新行的插入而单调增加。因此，按行ID排序的行在物理上是按插入顺序排列的。

博主PS：

自动生成的列官方文档原文是：a synthetic column

synthetic：

adj.(人工)合成的; 综合(型)的; 人造的
n.合成物; 合成纤维(织物); 合成剂

GEN_CLUST_INDEX：可以翻译问普通的聚集索引。General。

说人话就是如果你表里没有非空唯一索引列，那么就使用隐藏自增列作为聚簇索引

1.2 聚集索引如何加快查询速度

通过聚集索引访问行很快，因为索引搜索直接指向包含行数据的页面。如果表很大，与使用不同于索引记录的页面存储行数据的存储组织相比，聚集索引体系结构通常会节省磁盘I/O操作。

博主PS：

如果有一点B+树知识的朋友一定知道这里说的是什么了。

如果是纯小白。那么先阅读一下B+树存储结构。

1.3 二级索引与聚集索引的关系

聚集索引以外的索引称为二级索引。在InnoDB中，二级索引中的每条记录都包含该行的主键列，以及为二级索引指定的列。InnoDB使用这个主键值来搜索聚集索引中的行。

博主PS：

需要深刻记忆的地方是

1.不管是聚集索引还是二级索引，他的结构都是B+树。

2.聚集索引和二级索引的区别是

在聚集索引中，B+树叶子节点存储的数据是一整行数据。

在二级索引中，B+树叶子节点存储的数据是聚簇索引的主键。很多博客在这里写的是聚簇索引的id，但是主键不一定是id的。

3.这里又引出查询数据时，回表的知识。如果二级索引中的索引列无法覆盖到需要查到的数据，那么需要根据叶子节点的的主键，去聚簇索引查询叶子节点的整行数据。

4.辅助索引就是二级索引。翻译不同，叫法不同。（Secondary Indexes）

如果主键长，则二级索引会占用更多空间，因此主键短是有利的。

如果看到这里看不懂没事，我们在第二节先了解一下索引的物理结构。看完后再来看B+树的叶子节点的东西就能明白了。本博客是按官网索引的介绍的顺序写的博客。看完别忘记点赞收藏关注，一键三连~

2.InnoDB索引的物理结构

除了空间索引（Spatial Indexes）之外，InnoDB索引是B树数据结构

博主PS：

官方文档在这里写的就是b树：（原文）InnoDB indexes are B-tree data structures

为什么这里并不特指B+树呢，我认为因为B树包含B+树，B+树是B树在MySQL的Innodb引擎的变体，或者升级版。因此在介绍自家变体前，这里统称为B树，后面文中出现的B树都意为B+树。

空间索引使用R树，这是用于索引多维数据的专用数据结构。索引记录存储在其B树或R树数据结构的叶页中。

索引页的默认大小为16KB。（16KB写到手上，每天早上起来看一遍，虽然面试没被问到过，但是感觉大厂的卷王们会问，现在行情这么差，大厂也面不上我这样的卡拉米）

页面大小由MySQL实例初始化时的innodb_page_size设置决定。

当新记录插入到InnoDB聚集索引中时，InnoDB会尝试留出1/16的页面空间，以便将来插入和更新索引记录。如果按顺序（升序或降序）插入索引记录，则生成的索引页约为15/16。如果按随机顺序插入记录，则页面将从1/2到15/16。

博主PS：在这里不太明白什么意思

InnoDB在创建或重建B树索引时执行批量加载（从磁盘批量读数据）。这种创建索引的方法被称为有序索引构建。

innodb_fill_actor变量定义了在有序索引构建过程中每个B树页面上填充的空间百分比，剩余空间保留用于未来索引增长。空间索引不支持有序索引生成。

有关更多信息，请参阅第3节“排序索引构建”。

innodb_fill_actor设置为100会为将来的索引增长留出聚集索引页中1/16的空间。

博主PS：也就是说16KB的页空间，会留出1KB不装数据，用来装未来的索引。

如果InnoDB索引页的填充因子低于MERGE_THRESHOLD（如果未指定，则默认为50%），则InnoDB会尝试收缩索引树以释放该页。MERGE_THRESHOLD设置适用于B-树索引和R-树索引。有关更多信息，请参阅第17.8.11节“配置索引页的合并阈值”。

3.排序索引构建

InnoDB在创建或重建索引时执行大容量加载，而不是一次插入一条索引记录。这种索引创建方法也称为有序索引构建。空间索引不支持排序索引生成。

索引构建有三个阶段。

在第一阶段：扫描聚集索引，生成索引条目并将其添加到排序缓冲区。

当排序缓冲区已满时，将对条目进行排序并将其写入临时中间文件。这个过程也称为“运行”（官方文档原文为：“run”）。

在第二阶段：将一个或多个运行写入临时中间文件，对文件中的所有条目执行合并排序。

在第三个也是最后一个阶段：已排序的条目被插入到B树中。

在引入排序索引构建之前，索引条目是使用插入API，一次一条记录地插入到B树中的。这种方法包括打开B树光标（Cursor）以找到插入位置，然后使用乐观插入将条目插入B-树页面。如果由于页面已满而导致插入失败，则将执行悲观插入，这包括打开B树光标，并根据需要拆分和合并B树节点以查找条目的空间。这种“自上而下”的索引构建方法的缺点是搜索插入位置的成本以及B树节点的不断拆分和合并。

博主PS：

Cursor：

一种内部MySQL数据结构，表示SQL语句的结果集。通常与准备好的语句和动态SQL一起使用。它的工作方式与其他高级语言中的迭代器类似，根据请求从结果集中生成每个值。
尽管SQL通常为您处理游标的处理，但在处理性能关键代码时，您可能会深入研究内部工作原理。

这里的节点的不断拆分和合并想必大家已经联想到经常听见的页合并，页分裂了。就是这个意思。

有序索引构建使用“自下而上”的方法来构建索引。使用这种方法，在B树的所有级别上都会保留对最右侧叶页的引用。最右边的叶页被分配在必要的B树深度处的，并且条目根据它们的排序顺序被插入。一旦一个叶页已满，就会将一个节点指针附加到父页，并为下一次插入分配一个同级叶页。此过程一直持续到插入所有条目，这可能导致插入到根级别。分配同级页时，将释放对先前固定的叶页的引用，新分配的叶页将成为最右侧的叶页和新的默认插入位置。

3.1 为未来指数增长预留B树页面空间

要为未来的索引增长留出空间，可以使用innodb_fill_actor变量来保留一定比例的B树页面空间。例如，在有序索引构建过程中，将innodb_fill_actor设置为80将保留B树页面中20%的空间。

此设置同时适用于B树叶子页和非叶子页。它不适用于用于TEXT或BLOB条目的外部页面。

保留的空间量可能与配置的不完全一样，因为innodb_fill_actor值被解释为建议而不是硬限制。

3.2 排序索引构建和全文索引支持

全文索引支持排序索引生成。以前，SQL用于将条目插入到全文索引中。

3.3 排序索引构建和压缩表

对于压缩表，以前的索引创建方法将条目附加到压缩页和未压缩页。当修改日志（表示压缩页面上的可用空间）变满时，压缩页面将被重新压缩。

如果压缩由于空间不足而失败，页面将被拆分。

对于排序索引构建，条目仅附加到未压缩的页面。

当未压缩的页面变满时，它将被压缩。

自适应填充用于确保在大多数情况下压缩成功，但如果压缩失败，则会拆分页面并再次尝试压缩。此过程一直持续到压缩成功。有关B树页面压缩的更多信息，请参阅第17.9.1.5节“InnoDB表的压缩工作原理”。

3.4 排序索引生成和 Redolog

在有序索引生成过程中，将禁用redolog记录。

相反，有一个检查点来确保索引构建能够承受意外退出或失败。检查点强制将所有脏页刷入磁盘。在排序索引构建过程中，会定期向页面刷盘线程发出信号以刷盘脏页面，以确保可以快速处理检查点操作。通常，当干净页面的数量低于设置的阈值时，页面刷盘线程会刷盘脏页面。对于已排序的索引构建，脏页会被迅速刷盘，以减少检查点开销，并使I/O和CPU活动并行化。