一、InnoDB中b+树注意事项
1. 根页面位置万年不动
前文为了理解方便，写为先有数据页，目录项，再上层目录项，演变时候是由下而上。但是其实存储的时候实际上是由上而下。过程如下，
每当为某个表创建一个B+树索引（聚簇索引不是人为创建的，默认就有）的时候，都会为这个索引创建一个
根节点页面。最开始表中没有数据的时候，每个B+树索引对应的根节点中既没有用户记录，也没有目录项记录。随后向表中插入用户记录时，先把用户记录存储到这个
根节点中。当根节点中的可用
空间用完时继续插入记录，不是像此前说的再开一个叶子节点进行存储，此时会将根节点中的所有记录复制到一个新分配的页，比如页a中，然后对这个新页进行页分裂的操作，得到另一个新页，比如页b。这时新插入的记录根据键值（也就是聚簇索引中的主键值，二级索引中对应的索引列的值）的大小就会被分配到页a或者页b中，而根节点便升级为存储目录项记录的页。以上通俗易懂就是根节点如果满了，就把数据复制给出一份，向下传递。下面的太多又继续放到根节点，根节点继续把数据赋值给下层。根节点，也就是最上层节点始终不变。
这个过程特别注意的是：一个B+树索引的根节点自诞生之日起，便不会再移动。这样只要我们对某个表建立一个索引，那么它的根节点的页号便会被记录到某个地方，然后凡InnoDB存储引擎需要用到这个索引的时候，都会从那个固定的地方取出根节点的页号，从而来访问这个索引。
2.内节点中目录项记录的唯一性
我们知道B+树索引的内节点中目录项记录的内容索引列+页号的搭配，但是这个搭配对于二级索引来说有点不严谨。还index_demo表为例，假设这个表中的数据是这样的：
| c1 | c2 | c3 |
| ---- | ---- | ---- |
| 1 | 1 | 'u' |
| 3 | 1 | 'd' |
| 5 | 1 | 'y' |
| 7 | 1 | 'a' |
如果二级索引中目录项的内容只索引号+页号的搭配的话，那么c2列建立索引后的B+树应该长这样：
如果我们想要新插入一行记录，其中c1、c2、c3的值分别是：9、1、c，那么在修改这个为c2列建立的二级索引对应的B+树时便碰到了个大问题：由于页3中存储的目录项记录是由c2列+页号的值构成的，页3中的两条目录项记录对应的c2列的值都是1，那么我们这条新插入的记录到底应该放在页4中，还是应该放在页5中啊？答案是：对不起，懵了。
为了让新插入记录能找到自己在哪个页里，我们需要保证在B+树的同一层内节点的目录项记录除页号这个字段以外是唯一的。也就是你拿了哪个字段作为索引，那个字段必须是唯一值，在目录项记录页中，所以对于二级索引的内节点的目录项记录的内容实际上是由三个部分构成的：
索引列的值
主键值
页号
这样我们再插入记录(9, 1, 'c')时，由于页3中存储的目录项记录是由c2列+主键+页号的值构成的，可以先把新记录的c2列的值和页3中各目录项记录的c2列的值作比较，如果c2列的值相同的话，可以接着比较主键值，因为B+树同一层中不同目录项记录的c2列+主键的值肯定是不一样的，所以最后肯定能定位唯一的一条目录项记录，在本例中最后确定新记录应该被插入到页5中。
3.一个页面最少可以存储2条记录
一个B+树只需要很少的层级就可以轻松存储数亿条记录，查询速度相当不错！这是因为B+树本质上就是一个大的多层级目录，每经过一个目录时都会过滤掉许多无效的子目录，直到最后访问的存储真实数据的目录。那如果一个大的目录中只存放一个子目录是个啥效果呢？那就是目录层级非常非常非常多，而且最后的那个存放真实数据的目录中存放一条记录。费了半天劲只能存放一条真实的用户记录？所InnoDB的一个数据页至少可以存放两条记录
二、MyISAM索引的原理
B树索引适用存储引擎如表所示：
即使多个存储引擎支持同一种类型的索引，但是他们的实现原理也是不同的。Innodb和MyISAM默认的索引是Btree索引；而Memory默认的索引是Hash索引。
MyISAM引擎使B+Tree作为索引结构，叶子节点的data域存放的数据记录的地址。
MyISAM的索引方式都是“非聚簇”的，与InnoDB包含1个聚簇索引是不同的。
这里设表一共有三列，假设我们以col1为主键，上图是一个MyISAM表的主索引(Primary key)示意。可以看出*MyISAM的索引文件仅仅保存数据记录的地址**。在MyISAM中，主键索引和二级索引(Secondary key)在结构上没有任何区别，只是主键索引要求key是唯一的，而二级索引的key可以重复。如果我们在Col2上建立一个二级索引，则此索引的结构如下图所示:
三、MyISAM和InnoDB对比
MyISAM的索引方式都是“非聚簇”的，与InnoDB包含1个聚簇索引是不同的。
小结两种引擎中索引的区别：
① 在InnoDB存储引擎中，我们只需要根据主键值聚簇索引进行一次查找就能找到对应的记录，而MyISAM中却需要进行一回表操作，意味着MyISAM中建立的索引相当于全部都二级索引。
② InnoDB的数据文件本身就是索引文件，而MyISAM索引文件和数据文件分离的，索引文件仅保存数据记录的地址。
③ InnoDB的非聚簇索引data域存储相应记主键的值，而MyISAM索引记录的地址。换句话说，InnoDB的所有非聚簇索引都引用主键作为data域。
④ MyISAM的回表操作是十快速的，因为是拿着地址偏移量直接到文件中取数据的，反观InnoDB是通过获取主键之后再去聚簇索引里找记录，虽然说也不慢，但还是比不上直接用地址去访问。
⑤ InnoDB要求必须有主键MyISAM可以没有）。如果没有显式指定，则MySQL系统会自动选择一个可以非空且唯一标识数据记录的列作为主键。如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整型。
四、提醒
索引是个好东西，可不能乱建，它在空间和时间上都会有消耗：
空间上的代价
每建立一个索引都要为它建立一棵B+树，每一棵B+树的每一个节点都是一个数据页，一个页默认会占用16KB的存储空间，一棵很大的B+树由许多数据页组成，那就是很大的一片存储空间。
时间上的代价
每次对表中的数据进行增、删、改操作时，都需要去修改各个B+树索引。而且我们讲过，B+树每层节点都是按照索引列的值从小到大的顺序排序而组成了双向链表。不论是叶子节点中的记录，还是内节点中的记录（也就是不论是用户记录还是目录项记录）都是按照索引列的值从小到大的顺序而形成了一个单向链表。而增、删、改操作可能会对节点和记录的排序造成破坏，所以存储引擎需要额外的时间进行一些记录移位，页面分裂、页面回收等操作来维护好节点和记录的排序。如果我们建了许多索引，每个索引对应的B+树都要进行相关的维护操作，会给性能拖后腿。