【MySQL】索引

大佬教程收集整理的这篇文章主要介绍了【MySQL】索引，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。

在MysqL5.7之后存储引擎默认成了innodb，所以就主要讲解innodb的索引结构。

innodb存储引擎对于数据表结构

Innodb存储引擎用于管理数据的最小磁盘单位。常见的页类型有数据页，Undo页，系统页，事物数据页。下面主要分析的数据页。默认的页面大小为16kb，每个页中至少存储2条或以上的行记录

表空间

表空间分为了两种，这里简单的概括一下：
独立表空间：每一个表都将会生成以独立的文件方式来进行存储，每一个表都有一个.frm表描述文件，还有一个.ibd文件。 其中这个文件包括了单独一个表的数据内容以及索引内容，默认情况下它的存储位置也是在表的位置之中。
共享表空间： Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。

InnoDB把数据保存在表空间内，表空间可以看作是InnoDB存储引擎逻辑结构的最高层。本质上是一个由一个或多个磁盘文件组成的虚拟文件系统。InnoDB用表空间并不只是存储表和索引，还保存了回滚段、双写缓冲区等。

分片段(Segment)

段是表空间文件中的主要组织结构，它是一个逻辑概念，用来管理物理文件，是构成索引、表、回滚段的基本元素。

创建一个索引（B+树）时会同时创建两个段，分别是内节点段和叶子段，内节点段用来管理（存储）B+树非叶子（页面）的数据，叶子段用来管理（存储）B+树叶子节点的数据；也就是说，在索引数据量一直增长的过程中，所有新的存储空间的申请，都是从“段”这个概念中申请的。

页

页是InnoDB磁盘管理的最小单位 对于innodb来说就是 16KB 不过如果是Oracle 或者sqlserver就是4kb的大小。
这里单单指的是数据页，数据页里边存储的是每一行数据，有用过数据库客户端的可以理解为就是一条一条数据

Innodb的数据结构跟索引有什么关系

为什么要写这里，这里需要你知道索引在表页中起的作用
之前写过：https://blog.csdn.net/fangkang7/article/details/98973186

认识索引

在MysqL中，主要有四种类型：分别为BTree索引，哈希索引，Fulltext索引，R-tree索引

先介绍俩个概念，非叶节点，叶子节点

b+tree跟b-tree的区别

B+Tree相对于B-Tree有几点不同：
非叶子节点只存储键值信息。
所有叶子节点之间都有一个链指针。
数据记录都存放在叶子节点中。

每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null。

B+树
索引的底层原理就是B+Tree
只有叶子节点存储data，叶子节点包含了这棵树的所有键值，叶子节点不存储指针。

主索引与辅助索引

主键索引（主索引）：在叶子节点存放的是数据
二级索引（辅助索引）：在叶子节点处存放的是这个表的主键

普通的索引找在叶子节点主键，主键索引在叶子节点找数据

在 InnoDB 存储引擎中，每一个索引都对应一棵 B+ Tree，InnoDB 的索引主要分为主索引和辅助索引：

主索引：包含记录的文件按照某个 key 制定的顺序排序，这个 key 就是主索引，也就是主键，也被称为聚簇索引。因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚集索引。在 InnoDB 中，主索引的叶子节点存的是整行数据，这也意味着 InnoDB 中的表一定要有一个主索引；
辅助索引：某个 key 指定的顺序与文件记录的物理顺序不同，这个 key 就是辅助索引。InnoDB 中的辅助索引在叶子节点中并不存储实际的数据，只会包含主索引的值。这就意味着如果使用辅助索引进行数据的查找，只能查到主索引，然后根据这个主索引再次扫描以下主索引的树，进行一次回表操作；

索引在优化器中的执行流程

文章地址：https://blog.csdn.net/fangkang7/article/details/99443549

**索引B+Tree

B+tree是在二叉树的基础上演变来的。b+tree的定义实际上是比较的复杂的，b+tree视为磁盘或其他直接存取辅助设备设计的一种平衡查找树。在B+tree中，所有记录节点都是按键值的大小顺序存放在同一层的叶子节点上，由各叶子节点指针进行连接。
b+tree会根据指定的索引列的值排序：5,10,15,20,25,30,50,55,60,65,75,80,85,90

平衡二叉树的原理

平衡二叉树的查找性能是比较高的，但不是最高的只是接近最高性能。平衡二叉树的维护实际上代价是非常大的。通常来说，需要1次或者更多次的左旋和右旋来得到插入或更新后树的平衡性。
实例一：
当插入9这个值后，会围绕8进行一次左旋，以保证平衡

实例二
从左往右开始执行旋转

**hash索引

会发现name的索引类型还是为btree；这是innodb的特点，当前的name可以成为自适应哈希索引；是因为完全由InnoDB自己决定，不需要DBA人为干预。它是通过缓冲池中的B+树构造而来，且不需要对整个表建立哈希索引，因此它的数据非常快

如下：图 MysqL根据字段值创建对应的索引然后会以零散的方式存放

哈希索引值包含哈希值和行指针，而不存储字段值，所以不能使用索引的值避免数据库对于行的 读取(using indeX)。不过访问内存中的行的速度很快，索引大部分情况下这点并不影响；
哈希索引数据并不是按照索引值顺序存储的，所以也就无法用于排序。
哈希索引不能利用部分索引来查询(联合索引的情况) =》 因为哈希索引是通过内容计算到的哈希值。
哈希如果遇到大量的hash值相等的时候，一些索引维护操作的代价会很高

**全文索引（full-text）

ngram全文解析器
ngram就是一段文字里边连续的n个字的序列，ngram全文解析器能够对文本进行分词，每个单词是连续的序列，例如：用ngram全文解析器对“生日快乐”进行分词

添加全文索引

查看索引

添加完索引后后产生几个文件
FTS_0000000000000031_000000000000005c_INDEX_1~6.ibd这6个文件用于存储倒排索引，存储的是分词和位置以及document ID，根据分词的第一个字符值进行分区，映射到不同的文件中； 文件的命名规则为FTS_{TABLE_ID} {INDEXID}INDEX{N}.ibd
FTS_0000000000000031_BEING_deletED.ibd包含已经被删除的DOC_ID，但还没从全文索引数据中删掉； FTS_0000000000000031_deletED_CACHE.ibd 是前者的内存缓存（但是搜索了下代码，只有当fts_cache_t::deleted_doc_ids被使用时，才会在sync时转储到该表中，但并没有发现任何地方使用这个对象）
FTS_0000000000000031_BEING_deletED_CACHE.ibd 和 FTS_0000000000000031_BEING_deletED.ibd，包含了已经被删除索引记录并且正在从全文索引中移除的DOC ID，前者是后者的内存版本，这两个表主要用于辅助进行OPTIMIZE TABLE时将deletED/deletED_CACHED表中的记录转储到其中。
FTS_0000000000000031_CONfig.ibd，包含全文索引的内部信息，最重要的存储是FTS_SYNCED_DOC_ID，表示已经解析并刷到磁盘的doc id， 在崩溃恢复时，可以根据这个值判断哪些该重新解析并加入到索引cache中。

@H_197_234@

查询操作
1、按自然语言搜索模式查询

2、按布尔全文搜索模式查询

匹配既有没有实来的数据
MysqL> SELECT * FROM customers WHERE MATCH (Name) AGAINST (’-实来’ IN BooleAN MODE) limit 0,3;
Empty set (0.00 seC)

匹配相关的数据
MysqL> SELECT * FROM customers WHERE MATCH (Name) AGAINST (’>实来’ IN BooleAN MODE) limit 0,3;

大佬总结

以上是大佬教程为你收集整理的【MySQL】索引全部内容，希望文章能够帮你解决【MySQL】索引所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。