在InnoDB中，索引类别有四种，一般索引、惟一索引（换行符索引是特定的惟一索引）、全文索引。
B树在枝结点和枝叶结点储存数组、统计数据门牌号、结点提及 ，锯齿数（路子）总有一天比URL班莱班县1。比如说他们画的这棵树，每一结点储存三个URL，那么就会有四个操作符对准四个子结点。
MySQL中的B+Tree有三个特征：1、它的URL的数目是跟路子成正比的；
2、B+Tree的根结点和枝结Behren都不会储存统计数据，只有枝叶结点才储存统计数据。
3、B+Tree的每一枝叶结点增加了三个对准交界处枝叶结点的操作符，它的最后三个统计数据会对准下三个枝叶结点的第二个统计数据，逐步形成了三个科学规范二叉树的内部结构。
1)它是BTree的变型，BTree能化解的难题，它都能化解。BTree化解的三大难题（每一结点储存更少URL；路子更少）
2)扫库、扫表潜能大列佩季哈区（假如他们要对表进行全表扫描器，只须要结点枝叶结点就能了，不须要结点野草B+Tree领到大部份的统计数据）
3)B+Tree的硬盘理解力相对于BTree而言大列佩季哈区（根结点和枝结点不留存统计数据区，因此三个结点能留存更少的URL，一次硬盘读取的URL更少）
4)次序潜能大列佩季哈区（因为枝叶结点上有下三个统计数据区的操作符，统计数据逐步形成了链表）
5)工作效率更为平衡B+Tree总有一天是在枝叶结点领到统计数据，因此IO单次是平衡的）
建立索引，索引形式有三种。
HASH：以KV的形式索引统计数据，换句话说，它会依照索引表头聚合基元码和操作符，操作符对准统计数据。
第一个，它的时间维数是O(1)，查阅速率比较快。但是基元索引里头的统计数据不是按顺序储存的，因此不能用作次序。
第二个，他们在查阅统计数据的这时候要依照数组排序基元码，因此它根本无法全力支持下同查阅（=IN），不全力支持覆盖范围查询（><>=<=between and）
第二：假如表头多次重复值许多的这时候，会出现大量的基元冲突（采用拉链法化解），工作效率会降低。
在MyISAM里头，辅助索引也在这个.MYI文件里头。
辅助索引跟换行符索引储存
innodb
就是索引数组的逻辑顺序跟表统计数据行的物理储存顺序是一致的。(比如说字典的目录是按拼音次序的，内容也是按拼音次序的，按拼音次序的这种目录就叫聚集索引）。
InnoDB组织统计数据的形式就是（聚集）索引组织表（clusteredi ndex organize table）。假如说一张表建立了换行符索引，那么这个换行符索引就是聚集索引，决定统计数据行的物理储存顺序。
innoDB中，换行符索引和辅助索引是有三个主次之分的。刚才他们讲了，假如有换行符索引，那么换行符索引就是聚集索引。其他的索引统一叫做“二级索引”或者辅助索引。(二级索引索引统计数据的流程是这样的：当他们用name索引查阅一条记录，它会在二级索引的枝叶结点找到name=qingshan，领到主数组，也就是id=1，然后再到换行符索引的枝叶结点领到统计数据。)
假如一张表没有换行符怎么办？
1、假如他们定义了换行符(PRIMARYKEY)，那么InnoDB会选择换行符作为聚集索引。
2、假如没有显式定义换行符，则InnoDB会选择第二个不包含有NULL值的惟一索引作为换行符索引。
3、假如也没有这样的惟一索引，则InnoDB会选择内置6字节长的ROWID作为隐藏的聚集索引，它会随着行记录的写入而换行符递增。
在什么表头上索引？
1、在用作where判断order次序和join的(on）表头上建立索引
2、索引的个数不要过多。——浪费空间，更新变慢。
3、区分度低的表头，例如性别，不要建索引。——离散度太低，导致扫描器行数过多。
4、频繁更新的值，不要作为换行符或者索引。——页分裂
5、随机无序的值，不建议作为换行符索引，例如身份证、UUID。——无序，分裂
6、建立复合索引，而不是修改单列索引
什么这时候索引失效？
1、索引列上使用函数（replace\SUBSTR\CONCAT\sum count avg）、表达式排序（+-*/）
2、字符串不加引号，出现隐式转换
3、like条件中前面带%
4、负向查阅 NOTLIKE不能：!=（<>）和NOT IN在某些情况下能：
