一：Mysql索引数据类型的演变过程 :
二叉树-->平衡二叉树-->红黑树-->B-Tree-->B+Tree
从二叉树到红黑树都存在一个问题，就是树的深度太深而导致索引的效率低下
下面说下B-Tree和B+Tree
-
1 B-TreeB-Tree.png
-
2 B+TreeB+Tree.png
区别：
1：在B-Tree中，我们要查询的数据可能在非叶子节点；而在B+Tree中都是在叶子节点
2：也正是因为第一个原因，所以目前索引的数据结构采用的是B+Tree，因为cpu在读取磁盘数据时，都是一块一块内存读取的，每次读取16kb的内容，在B-Tree中，索引对应的整行数据就占据了大部分内存，能够读取到的索引有限，所以优化成了B+Tree的数据结构。
3.另外，在MyISAM存储引擎中，索引对应的数据不是行数据，而是该行数据在磁盘中的地址，而在InnoDB中，叶子节点的索引存储的是整行数据，所以比MyISAM少了一次IO
二：索引的优点
- 大大减少了服务器扫描的数据量，减少了IO次数
- 将随机IO变为顺序IO
- 帮助服务器避免排序和临时表
三：索引的用处
- 快速查找匹配WHERE子句的行
- 如果可以在多个索引间进行选择，msyql通常会使用找到最少行的索引
- 如果具有多列索引，优化器可以使用索引的任何最左前缀进行查找
- 当有表连接的时候，从其他表检索行数据
- 查找特定索引列的min或max
- 如果排序或分组时，在索引的最左前缀上完成的，则对表进行分组和排序
- 在某些情况下，可优化查询以检索值而无需查找数据行
四：索引的分类
- 主键索引：给主键建立的索引
- 唯一索引：给唯一键建立的索引
- 普通索引：给普通列建立的索引
- 全文索引：很少用，在text中使用
- 联合索引：将多个列组合成一个索引
五：技术名词：
回表：通过索引查询到叶子节点后，叶子节点对应的是行数据的主键，需要通过主键再次查询对应的数据，这就是回表
覆盖索引：需要查询的属性也是索引列，就不需要回表，直接返回
-
最左匹配：最左边的优先，任何连续的索引都能匹配上，但是遇到范围查询就会停止匹配(>、<、between、like)。最左匹配原则都是针对联合索引来说的，索引的数据结构是B+Tree，所以联合索引的结构也是B+Tree，但是联合索引的键值有多列，所以联合索引按照最左原则来建立索引。
假如有一个联合索引(a,b),B+Tree的数据结构图如下：
联合索引.png从图中我们可以看到，a的顺序是有序的：1，1，2，2，3，3 b的顺序是无序的：1，2，1，4，1，2。所以如果查询条件where b = 2，索引条件是不生效的，因为b是无序的。
但是如果在a确定的情况下，b是有序的，所以按照最左前缀原则，如果遇到范围查询，后面的索引列都会无效
如果查询条件是WHERE a = 1 and b = 1 a,b字段都可以使用索引，因为在a确定的条件下，b相对来说是有序的。如果条件是WHERE a > 1 and b = 1,a索引是生效的，b所以就无效了，因为a的值变成了一个范围，在这个范围内，b是无序的
再比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的联合索引，d是用不到索引的，因为c字段是一个范围查询，它之后的字段会停止匹配。 索引下推：有联合索引(name,age)，以前版本：在执行引擎层先通过索引列name进行匹配，查询到数据后，再在server层通过age筛选得到匹配的数据；目前都是在执行引擎层，name和age同时进行匹配，这就叫索引下推
四：如果有下面的sql语句，下面哪种联合索引比较好呢？
SELECT * FROM user WHERE name = "" AND age = "";
SELECT * FROM user WHERE name = ""
SELECT * FROM user WHERE age = ""
- 1：建立联合索引 name,age
- 2：建立联合索引 age,name
相比来说，第二种会好一点，因为age属性会比name属性要小
