mysql基础-InnoDB 中的索引

1. InnoDB 中的索引

InnoDB 中的索引自然也是按照 B+树来组织的，前面我们说过 B+树的叶子节点用来放数据的，但是放什么数据呢?索引自然是要放的，因为 B+树的作用本来就是就是为了快速检索数据而出的一种数据结构，不放索引放什么呢?但是数据库中的表，数据才是我们真正需要的数据，索引只是辅助数据，甚至于一个表可以没有自定义索引。InnoDB 中的数据到底是如何组织的?

1. 聚集索引/聚簇索引

InnoDB 中使用了聚集索引，就是将表的主键用来构造一棵 B+树，并且将整张表的行记录数据存放在该 B+树的叶子节点中。也就是所谓的索引即数据，数据即索引。由于聚集索引是利用表的主键构建的，所以每张表只能拥有一个聚集索引。
聚集索引的叶子节点就是数据页。换句话说，数据页上存放的是完整的每行记录。因此聚集索引的一个优点就是:通过过聚集索引能获取完整的整行数据。另一个优点是:对于主键的排序查找和范围查找速度非常快。
如果我们没有定义主键呢?MySQL 会使用唯一性索引，没有唯一性索引， MySQL 也会创建一个隐含列 RowID 来做主键，然后用这个主键来建立聚集索引。

2. 辅助索引/二级索引

上边介绍的聚簇索引只能在搜索条件是主键值时才能发挥作用，因为 B+树中的数据都是按照主键进行排序的,那如果我们想以别的列作为搜索条件怎么办?我们一般会建立多个索引，这些索引被称为辅助索引/二级索引。
对于辅助索引(Secondary Index，也称二级索引、非聚集索引)，叶子节点并不包含行记录的全部数据。叶子节点除了包含键值以外，每个叶子节点中的索引行中还包含了一个书签( bookmark)。该书签用来告诉 InnoDB 存储引擎哪里可以找到与索引相对应的行数据。因此 InnoDB 存储引擎的辅助索引的书签就是相应行数据的聚集索引键。

回表

辅助索引的存在并不影响数据在聚集索引中的组织，因此每张表上可以有多个辅助索引。当通过辅助索引来寻找数据时，InnoDB 存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键，然后再通过主键索引(聚集索引) 来找到一个完整的行记录。这个过程也被称为回表。也就是根据辅助索引的值查询一条完整的用户记录需要使用到 2 棵 B+树----一次辅助索引，一次聚集索引。

为什么我们还需要一次回表操作呢?直接把完整的用户记录放到辅助索引 d 的叶子节点不就好了么?如果把完整的用户记录放到叶子节点是可以不用回表，但是太占地方了，相当于每建立一棵 B+树都需要把所有的用户记录再都拷贝一遍，这就有点太浪费存储空间了。而且每次对数据的变化要在所有包含数据的索引中全部都修改一次，性能也非常低下。
很明显，回表的记录越少，性能升就越高，需要回表的记录越多，使用二级索引的性能就越低，甚至让某些查询宁愿使用全表扫也不使用二级索引。
那什么时候采用全表扫的方式，什么时候使用采用二级索引 + 回表的方式去执行查询呢?这个就是查询优化器做的工作，查询优化器会事先对表中的记录计算一些统计数据，然后再利用这些统计数据根据查询的条件来计算一下需要回表的记录数，需要回表的记录数越多，就越倾向于使用全表扫，反之倾向于使用二级索引 + 回表的方式。

3. 联合索引/复合索引

前面我们对索引的述，隐含了一个条件，那就是构建索引的字段只有一个，但实践工作中构建索引的完全可以是多个字段。所以，将表上的多个列组合起来进行索引我们称之为联合索引或者复合索引，比如 index(a,b)就是将 a,b 两个列组合起来构成一个索引。
千万要注意一点，建立联合索引只会建立 1 棵 B+树，多个列分别建立索引会分别以每个列则建立 B+树，有几个列就有几个 B+树，比如，index(note)、 index(b)，就分别对 note,b 两个列各构建了一个索引。
index(note,b)在索引构建上，包含了两个意思: 1、先把各个记录按照 note 列进行排序。
2、在记录的 note 列相同的情况下，采用 b 列进行排序

4. 覆盖索引/索引覆盖

既然多个列可以组合起来构建为联合索引，那么辅助索引自然也可以由多个列组成。
InnoDB 存储引擎支持覆盖索引(covering index，或称索引覆盖)，即从辅助索引中就可以得到查询的记录，而不需要查询聚集索引中的记录。使用覆盖索引的一个好处是辅助索引不包含整行记录的所有信息，故其大小要远小于聚集索引，因此可以减少大量的 IO 操作。所以记住，覆盖索引并不是索引类型的一种。

5. 自适应哈希索引

InnoDB 存储引擎除了我们前面所说的各种索引，还有一种自适应哈希索引，我们知道 B+树的查找次数,取决于 B+树的高度,在生产环境中,B+树的高度一般为 3~4 层,故需要 3~4 次的 IO 查询。
所以在 InnoDB 存储引擎内部自己去监控索引表，如果监控到某个索引经常用，那么就认为是热数据，然后内部自己创建一个 hash 索引，称之为自适应哈希索引( Adaptive Hash Index,AHI)，创建以后，如果下次又查询到这个索引，那么直接通过 hash 算法推导出记录的地址，直接一次就能查到数据，比重复去 B+tree 索引中查询三四次节点的效率高了不少。
InnoDB 存储引擎使用的哈希函数采用除法散列方式，其冲突机制采用链表方式。注意，对于自适应哈希索引仅是数据库自身创建并使用的，我们并不能对其进行干预。通过命令 show engine innodb status\G 可以看到当前自适应哈希索引的使用状况。
哈希索引只能用来搜索等值的查询,如 SELECT* FROM table WHERE index co=xxx。而对于其他查找类型,如范围查找,是不能使用哈希索引的,
因此这里出现了 non- hash searches/s 的情况。通过 hash searches: non- hash searches 可以大概了解使用哈希索引后的效率。
由于 AHI 是由 InnoDB 存储引擎控制的,因此这里的信息只供我们参考。不过我们可以通过观察 SHOW ENGINE INNODB STATUS 的结果及参数 innodb_adaptive_hash_index 来考虑是禁用或启动此特性,默认 AHI 为开启状态。

6. 全文检索之倒排索引

什么是全文检索(Full-Text Search)?它是将存储于数据库中的整本书或整篇文章中的任意内容信息查找出来的技术。它可以根据需要获得全文中有关章、节、段、句、词等信息，也可以进行各种统计和分析。我们比较熟知的 Elasticsearch、 Solr 等就是全文检索引擎，底层都是基于 Apache Lucene 的。

举个例子，现在我们要保存唐宋诗词，数据库中我们们会怎么设计?诗词表我们可能的设计如下:

要根据朝代或者作者寻找诗，都很简单，比如“select 诗词全文 from 诗词表 where 作者=‘李白’”，如果数据很多，查询速度很慢，怎么办?我们可以在对应的查询字段上建立索引加速查询。
但是如果我们现在有个需求:要求找到包含“望”字的诗词怎么办?用
“select 诗词全文 from 诗词表 where 诗词全文 like‘%望%’”，这个意味着要扫库中的诗词全文字段，逐条比对，找出所有包含关键词“望”字的记录。基本上，数据库中一般的 SQL 优化手段都是用不上的。数量少，大概性能还能接受，如果数据量稍微大点，就完全无法接受了，更何况在互联网这种海量数据的情况下呢?怎么解决这个问题呢，用倒排索引。
比如现在有:
蜀道难(唐)李白蜀道之难难于上青天，侧身西望长咨嗟。
静夜思(唐)李白举头望明月，低头思故乡。
春台望(唐)李隆基暇景属三春，高台聊四望。
鹤冲天(宋)柳永黄金榜上，偶失龙头望。明代暂遗贤，如何向?未遂风云便，争不恣狂荡。何须论得丧?才子词人，自是白衣卿相。烟花巷陌，依约丹青屏障。幸有意中人，堪寻访。且恁偎红翠，风流事，平生畅。青春都一饷。忍把浮名，换了浅斟低唱!
都有望字，于是我们可以这么保存

如果查哪个诗词中包含上，怎么办，上述的表格可以继续填入新的记录

其实，上述诗词的中每个字都可以作为关键字，然后建立关键字和文档之间的对应关系，也就是标识关键字被哪些文档包含。
所以，倒排索引就是，将文档中包含的关键字全部取处理，然后再将关键字和文档之间的对应关系保存起来，最后再对关键字本身做索引排序。用户在检索某一个关键字是，先对关键字的索引进行查找，再通过关键字与文档的对应关系找到所在文档。
在存储在关系型数据库中的数据，需要我们事先分析将数据拆分为不同的字段，而在 es 这类的存储中，需要应用程序根据规则自动取关键字，并形成对应关系。
这些预先取的关键字，在全文检索领域一般被称为 term(词项)，文档的词项取在 es 中被称为文档分析，这是全文检索很核心的过程，必须要区分哪些是词项，哪些不是，比如很多场景下，apple 和 apples 是同一个东西，望和看其实是同一个动作。
从 InnoDB 1.2.x 版本开始，InnoDB 存储引擎开始支持全文检索，对应的 MySQL 版本是 5.6.x 系列。不过 MySQL 从设计之初就是关系型数据库，存储引擎虽然支持全文检索，整体架构上对全文检索支持并不好而且限制很多，比如每张表只能有一个全文检索的索引，不支持没有单词界定符( delimiter)的语言，如中文、日语、韩语等。
所以如果有大批量或者专门的全文检索需求，还是应该选择专门的全文检索引擎，毕竟 Elastic 靠着全文检索起家，然后产品化、公司化后依赖全文检索不断扩充产品线和应用场景，并推出商业版本的解决方案然后融资上市，现在的市值已达 100 亿美元(2021/03/24-纽约证券交易所中的市值 99.84 亿美元)。