MySQL高级知识（四）——索引结构

mysql有七种引擎，mysql不同引擎的索引结构选择有些也不同。mysql总共有BTree索引、B+Tree索引、聚簇索引与非聚簇索引、full-text全文索引、Hash索引以及R-Tree索引。

参考资料：
索引的实现原理：MySQL索引实现原理

1. B-Tree索引（即BTree）

此部分可查看此博主的博客：https://blog.csdn.net/endlu/article/details/51720299
对BTree、B-Tree、B+Tree、B*Tree区别，请看：https://blog.csdn.net/andyzhaojianhui/article/details/76988560
通俗BTree理解：程序员小灰：什么是B-树？

1.1. 原理图

此处我们以下面的图做简要说明：

1. 初始化介绍
   一颗b树，浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示），
   如磁盘块1包含数据项17和35，包含指针P1、P2、P3，
   P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。
   真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。
   非叶子节点不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。

2. 查找过程
   如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。

3. 真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。

MyiSAM普通索引就是这个结构

1.2. 关于时间复杂度

同一问题可用不同算法解决，而一个算法的质量优劣将影响到算法乃至程序的效率。算法分析的目的在于选择合适算法和改进算法。

• 1 N logN 分别表示数据与查询次数之间的关系。
• 常数 1*c 表示查询最快的方式。查询次数不随数据的增加而增加
• 变量 N 表示查询次数随数据数量的增加而增加
• 对数 logN 表示查询次数与数据数量成对数关系。 介于常数与 N 之间。
• n*logN 表示使用的复合方法。

2. B+Tree索引

通俗理解B+Tree：程序员小灰：什么是B+树？

2.1. 原理图

一颗m阶的B+树和m阶的B_树的差异在于：

1. 有n棵子树的结点中含有n个关键字； (而B树是n棵子树有n-1个关键字)

2. 所有的叶子结点中包含了全部关键字的信息，及指向含有这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大的顺序链接。(而B树的叶子节点并没有包括全部需要查找的信息)

3. 所有的非终端结点可以看成是索引部分，结点中仅含有其子树根结点中最大（或最小）关键字。 (而B 树的非终节点也包含需要查找的有效信息)

2.2. B+Tree优点

1. B±tree的磁盘读写代价更低
   B±tree的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B 树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。

举个例子，假设磁盘中的一个盘块容纳16bytes，而一个关键字2bytes，一个关键字具体信息指针2bytes。一棵9阶B-tree(一个结点最多8个关键字)的内部结点需要2个盘快。而B+ 树内部结点只需要1个盘快。当需要把内部结点读入内存中的时候，B 树就比B+ 树多一次盘块查找时间(在磁盘中就是盘片旋转的时间)。

2. B±tree的查询效率更加稳定
   由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

这也就是为什么B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引？

2.3. B-Tree与B+Tree区别：

结论在内存有限的情况下，B+TREE 永远比 B-TREE好。无限内存则后者方便

• B-树的关键字和记录是放在一起的，叶子节点可以看作外部节点，不包含任何信息；B+树叶子节点中只有关键字和指向下一个节点的索引，记录只放在叶子节点中。(一次查询可能进行两次i/o操作)
• 在B-树中，越靠近根节点的记录查找时间越快，只要找到关键字即可确定记录的存在；而B+树中每个记录的查找时间基本是一样的，都需要从根节点走到叶子节点，而且在叶子节点中还要再比较关键字。从这个角度看B-树的性能好像要比B+树好，而在实际应用中却是B+树的性能要好些。因为B+树的非叶子节点不存放实际的数据，这样每个节点可容纳的元素个数比B-树多，树高比B-树小，这样带来的好处是减少磁盘访问次数。尽管B+树找到一个记录所需的比较次数要比B-树多，但是一次磁盘访问的时间相当于成百上千次内存比较的时间，因此实际中B+树的性能可能还会好些，而且B+树的叶子节点使用指针连接在一起，方便顺序遍历（例如查看一个目录下的所有文件，一个表中的所有记录等），这也是很多数据库和文件系统使用B+树的缘故。

3. 聚簇索引与非聚簇索引

3.1. 聚簇索引含义

• 所谓聚簇索引，就是指主索引文件和数据文件为同一份文件，聚簇索引主要用在Innodb存储引擎中。在该索引实现方式中B+Tree的叶子节点上的data就是数据本身，key为主键，如果是一般索引的话，data便会指向对应的主索引。
• 聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。
• 术语‘聚簇’表示数据行和相邻的键值进错的存储在一起。

如下图，左侧的索引就是聚簇索引，因为数据行在磁盘的排列和索引排序保持一致。

3.2. 聚簇索引优缺点

• 聚簇索引的好处：
  按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不用从多个数据块中提取数据，所以节省了大量的io操作。
• 聚簇索引的限制：
  对于mysql数据库目前只有innodb数据引擎支持聚簇索引，而Myisam并不支持聚簇索引。
  由于数据物理存储排序方式只能有一种，所以每个Mysql的表只能有一个聚簇索引。一般情况下就是该表的主键。
  为了充分利用聚簇索引的聚簇的特性，所以innodb表的主键列尽量选用有序的顺序id，而不建议用无序的id，比如uuid这种。（参考聚簇索引的好处。）
  这里说明了主键索引为何采用自增的方式：1、业务需求，有序。2、能使用到聚簇索引

3.3. 非聚簇索引含义

• 非聚集索引则就是普通索引了，仅仅只是对数据列创建相应的索引，不影响整个表的物理存储顺序。
  主键索引中，叶节点的data域存放的是数据记录的地址，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。（MYISAM采用此种索引方式）。

3.4. 区别

1. 聚集索引表里数据物理存储顺序和主键索引的顺序一致，所以如果新增数据是离散的，会导致数据块趋于离散，而不是趋于顺序。而非聚集索引表数据写入的顺序是按写入时间顺序存储的。
2. 聚簇索引索引的叶节点就是数据节点；而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。

3.5. 适用场景

动作描述	使用聚集索引	使用非聚集索引
列经常被分组排序	Y	Y
一个或极少不同的值	N	N
返回某范围内的数据	Y	N
小数目的不同值	Y	N
大数目的不同值	N	Y
外键	Y	Y
主键	Y	Y
频繁更新的列	N	Y
频繁修改索引列	N	Y

4. full-text全文索引

全文索引详细请查看：https://blog.csdn.net/mrzhouxiaofei/article/details/79940958

4.1. 全文索引用法

• 模糊查询
  SELECT * FROM article WHERE content LIKE ‘%查询字符串%’;
• 全文索引用match+aginst方式查询
  SELECT * FROM article WHERE MATCH(title,content) AGAINST (‘查询字符串’);
  注意： match() 函数中指定的列必须和全文索引中指定的列完全相同，否则就会报错，无法使用全文索引，这是因为全文索引不会记录关键字来自哪一列。如果想要对某一列使用全文索引，请单独为该列创建全文索引。

全文索引的查询效率比模糊查询的效率明显提升很多。

限制：

• mysql5.6.4以前只有Myisam支持，5.6.4版本以后innodb才支持，但是官方版本不支持中文分词，需要第三方分词插件。
  5.7以后官方支持中文分词。
• 随着大数据时代的到来，关系型数据库应对全文索引的需求已力不从心，逐渐被 solr,elasticSearch等专门的搜索引擎所替代。

4.2. 全文索引命令

• 创建

1. 创建表时创建全文索引

create table fulltext_test (
    id int(11) NOT NULL AUTO_INCREMENT,
    content text NOT NULL,
    tag varchar(255),
    PRIMARY KEY (id),
    FULLTEXT KEY content_tag_fulltext(content,tag)  // 创建联合全文索引列
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

2. 在已存在的表上创建全文索引
   create fulltext index content_tag_fulltext on fulltext_test(content,tag);
3. 通过 SQL 语句 ALTER TABLE 创建全文索引
   alter table fulltext_test add fulltext index content_tag_fulltext(content,tag);

• 修改
  修改个 O，直接删掉重建。
• 删除

1. 直接使用 DROP INDEX 删除全文索引
   drop index content_tag_fulltext on fulltext_test;
2. 通过 SQL 语句 ALTER TABLE 删除全文索引
   alter table fulltext_test drop index content_tag_fulltext;

4.3. 两种全文索引

1. 自然语言的全文索引

默认情况下，或者使用 in natural language mode 修饰符时，match() 函数对文本集合执行自然语言搜索，上面的例子都是自然语言的全文索引。

自然语言搜索引擎将计算每一个文档对象和查询的相关度。这里，相关度是基于匹配的关键词的个数，以及关键词在文档中出现的次数。在整个索引中出现次数越少的词语，匹配时的相关度就越高。相反，非常常见的单词将不会被搜索，如果一个词语的在超过 50% 的记录中都出现了，那么自然语言的搜索将不会搜索这类词语。上面提到的，测试表中必须有 4 条以上的记录，就是这个原因。

这个机制也比较好理解，比如说，一个数据表存储的是一篇篇的文章，文章中的常见词、语气词等等，出现的肯定比较多，搜索这些词语就没什么意义了，需要搜索的是那些文章中有特殊意义的词，这样才能把文章区分开。

2. 布尔全文索引

在布尔搜索中，我们可以在查询中自定义某个被搜索的词语的相关性，当编写一个布尔搜索查询时，可以通过一些前缀修饰符来定制搜索。

MySQL 内置的修饰符，上面查询最小搜索长度时，搜索结果 ft_boolean_syntax 变量的值就是内置的修饰符，下面简单解释几个，更多修饰符的作用可以查手册

• +：必须包含该词
• -：必须不包含该词
• <： 降低该词的相关性，查询的结果靠后（> 靠前）
• (*)：星号 通配符，只能接在词后面

例如：
select * test where match(content) against('a*' in boolean mode);

全文索引会碰到一个问题，就是mysql设置最小搜索长度，MyISAM为4，InnoDB为3，需要修改才能搜索低于4以下的全文索引。

5. Hash索引

参考资料：
数据库中的索引技术——哈希索引

5.1. Hash索引含义

• 哈希索引（hash index）基于哈希表实现，只有精确匹配索引所有列的查询才有效。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码（hash code），哈希码是一个较小的值，并且不同键值的行计算出来的哈希码也不一样。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。

• 对于hash相同的，采用链表的方式解决冲突。类似于hashmap。因为索引的结构是十分紧凑的，所以hash索引的查询很快。

• Hash索引只有Memory, NDB两种引擎支持，Memory引擎默认支持Hash索引，如果多个hash值相同，出现哈希碰撞，那么索引以链表方式存储。
  NoSql采用此中索引结构。
  

5.2. Hash索引优缺点

• 优点：

1. 快速查询：参与索引的字段只要进行Hash运算之后就可以快速定位到该记录，时间复杂度为1

• 缺点：

2. 哈希索引只包含哈希值和行指针，所以不能用索引中的值来避免读取行
3. 哈希索引数据并不是按照索引值顺序存放的，所以就无法用于排序和范围查询
4. 哈希索引也不支持部分索引列查询，因为哈希索引始终是使用索引列的全部数据进行哈希计算的。
5. 哈希索引只支持等值比较查询，如=、in()、<=、>=操作
6. 如果哈希冲突较多，一些索引的文虎操作的代码也会更高。

6. R-Tree索引

参考资料：
MySQL · 引擎特性 · 初识 MySQL GIS 及 InnoDB R-TREE

• 和普通的BTREE不同，R-TREE专门用来表示空间数据类型，其存储的记录类型是该空间数据所能表示的最小边界的矩形，简称MBR
• 对于大多数空间类型，MBR记录了能保卫这些空间的最小矩形；对于水平或垂直的直线，MBR实际上记录的是直线；对于POINT，MBR表示的是一个退化成点的矩形。

一颗R-TREE可用下图表示(R-TREE)

其中叶子节点记录包含了MBR以及指向的聚集索引记录，非叶子节点记录包含了指向叶子节点的指针，及对应叶子节点记录所组成的MBR。目前MySQL只支持二维数据的索引。

R-Tree在mysql很少使用，仅支持geometry数据类型，支持该类型的存储引擎只有myisam、bdb、innodb、ndb、archive几种。
相对于b-tree，r-tree的优势在于范围查找。