mysql索引总结

b树索引

一般以B+树和b+树为主，只所以不用avl或者红黑树的原因主要是考虑到io磁盘(可以想象为每次查询要往下一层时，就需要往磁盘上拉一次，这时候很费时间)，b树的特点就是具有树的特性，层数少。

1. 聚集索引

   • 用表的主键构建的索引，叶子节点里会存放完整的行信息

2. 辅助索引（非聚集索引）

   • 索引键不是主键，索引的叶子节点里存放的也不是完整行信息，而是索引键的键值和一个书签，书签里存放着可以找到完整行信息的数据（可以认为是主键）

   • todo 这里有一个坑点（回表），如果你用辅助索引查询非索引键或者主键的话，那么查询步骤会如下：
     先在辅助索引上查询到主键（假设这里有3次磁盘io），再用主键索引查询叶子节点（3次磁盘io），磁盘io是正常查询2倍。

3. b树索引的应用

   • 联合索引

     • 相较于一般的索引，区别在于它是多列的键的索引

       1.多列的索引也是遵循b树的原则，假设（a，b）作为索引，那么b+的建树原则就是优先判断a，在a相等的情况下判断b。在客户端的应用就是最左匹配原则
       2.在建索引的时候，b列就已经有序了，那么在查询的就可以省略对b列的排序时间

   • 覆盖索引

     • 只是一种优化，避免回表的优化。如果是非聚集索引，避免查询索引未存储的列

     1.不回表，减少一半次数的io操作
     2.辅助索引上的存储内容远少于聚集索引，可以减少io
     3.对于一些非查询

hash索引

hash所以hash表的数据结构为底层，所以特性是单值查询很快 ，但是不支持范围查询。

全文检索-倒排索引

在辅助表中存储了单词与单词自身在一个或多个文档中所在位置之间的映射，通常利用关联表实现,有两种方式（mysql用的方式2），如下：

1. invert file index（单词，单词所在的文档）
   
2. full invert index（单词，（单词所在的文档，在文档中具体位置））
   

   mysql 对此还一个优化叫fts index cache（全文索引缓存），索引记录在缓存中，如果我们对外面的表做更新操作，那么也会对fts index cache更新，都是磁盘上的辅助表是不会现在更新，会在之后批量更新。