索引是帮助Mysql高效获取数据的排序好的数据结构
索引查询其实是磁盘IO的一次读写操作，IO的操作直接影响性能。所以我们SQL的优化其实就是减少SQL语句执行时IO的操作。
索引的数据结构 二叉树： 当用的索引列是从小到大的时候，则索引结构就变成了链表，如果要查询的结点在最后一个，也就是全部遍历一遍，就没有起来索引快速查找到效果了。
红黑树：（平衡二叉树） 当存储的数据量很大时，索引的数据也就变得很大，树的高度也就很变得很大。自然查询次数也就变大了。
hash表 B-Tree B+ Tree 现在目前mysql索引的底层结构就是用B+Tree组织的。 B+Tree（B-Tree变种） 非叶子节点不存储data, 只存储索引（冗余）， 可以放更多的索引 叶子节点包含所有索引字段 叶子节点用指针连接，提高区间访问的性能，而且一定是按主键顺序连接的
查找逻辑： 先将根结点load进内存查询，找到下一个结点的地址，再load到内存查询。而不是一次性就将所有结点都load进内存。这样一来每次也就加载16k的内存，大大节省内存使用。
内存页是按16K每页。 通过show global status like 'Innodb page size';可以查看 B+树的非叶子结点只存索引列以及其他非叶子结点的地址，（每个地址连接下的叶子也是按二叉树的原则存储的,即左子树 < 根结点 <= 右子树)。 如果按主键列是整型(8byte)+地址(6byte),则每页可存1024*16/(8+4) = 1170个结点为数据。 如果叶子结点存(主键列+数据=1k), 如果一颗3层结构的数,总共可能存储多少条记录？ 1170 * 1170 * 16 * 1 = 2000+万条记录。 也就是说查询2000万条记录只需要进行3次的IO的操作。 这就是为何B+Tree被运用在mysql的索引结构中的原因（快，省）
存储引擎：主要是作用于表，而不是库。同一库中是可以有不同存储引擎的表存在的。
MyIsam存储引擎
每个索引结构存储的是索引字段的值，以及数据记录在磁盘文件所在地址，并不是数据记录
未完整，待续
