《InnoDB存储引擎》第五章——索引与算法

B+树索引

  MySQL在5.5版本之前一个被人诟病的问题是：对于索引的添加删除的DDL操作，会直接让该表的服务不可用
  对于索引的添加或者删除这种DDL操作的过程是：创建临时表，定义新的表结构，然后将原数据导入临时表中，并且删除原表
  为了解决上述问题，InnoDB通过FIC、OSC、Online DDL，保证对辅助索引各种操作时，都可以进行读写，但是这个读写是否加锁也是由参数决定，分别有none、share、exclusive、default，分别是读写，读，读写均不可以，默认即从none开始往下尝试可不可以

Cardinality值

  对于表中的字段，可取值的范围越大，那么建立索引的意义就越大，相对应的参数是cardinality值，用来表示索引中不重复记录数量的预估值
  InnoDB内部对更新cardinality信息的策略为：
1.表中1/16的数据发生过变化
2.stat_modified_counter>=2e9

  InnoDB内部对于cardinality值的获得是靠采样的方法

1. 获取所有叶子结点的数量
2. 随机取8个叶子结点，统计每个页不同记录的个数，分别为p1,p2…p8
3. 预估值为(p1+p2+…+p8) * A / 8

B+树索引的使用

  覆盖索引的好处除了可以不用回表，在进行某些统计问题而言，可以直接通过覆盖索引来统计，相比于聚集索引，减小了IO操作
  MySQL5.6开始支持(Multi-Range Read)MRR优化，目的是为了减少磁盘的随机访问，转化为较为顺序的数据访问

1. 在查询辅助索引时，根据得到的索引结果，按照主键进行排序，再进主键索引里查找
2. 减少缓冲池中页被替换的次数
3. 批量处理对键值的查询操作

  InnoDB会将查询到的辅助索引键值存放在一个缓存中

  ICP优化
  根据索引定位取出数据的时候，就提前对索引进行判断然后过滤，可以大大提高效率

全文检索

倒排索引：也是一种索引结构，在辅助表中存储了单词与单词自身在一个或者多个文档中所在位置的映射，倒排索引在磁盘上的存储形式是由有限状态机转和字典树的结合而来的数据结构，FST(稍显复杂，还没有完全掌握)

总结起来 B+ 树不适合作为全文搜索索引主要有以下两个原因：

1. 全文索引的文本字段通常会比较长，索引值本身会占用较大空间，从而会加大 B+ 树的深度，影响查询效率。
2. 全文索引往往需要全文搜索，不遵循最左匹配原则，使用 B+ 树可能导致索引失效。

  InnoDB1.2.x版本开始，InnoDB开始支持全文索引，之前只有myisam支持
  可以通过全文索引来进行检索