一、索引的类型
MySQL中，索引是在存储引擎层实现的，而不是服务器层，所以没有统一的标准。
MySQL支持的索引类型如下：
1、B-Tree索引（也包括B+Tree索引，统称为B-Tree索引，只是数据结构上的不同，特性上是一样的）
使用B-Tree数据结构来存储数据，实际上很有存储引擎使用的是B+Tree。关于BTree、B-Tree、B+Tree的区别请看本博客的附件。
InnoDB就是使用的B+Tree索引。
B-Tree通常意味着所有的值都是按顺序存储的，并且每一个叶子页到跟的距离相同。
B-Tree对索引列是顺序组织存储的，所以很适合查找范围数据。
B-Tree索引适合用于全键值、键值范围或键前缀查找，其中键前缀查找只适合用于根据最左前缀查找。
举例说明：
数据如下：
a、全值匹配
对索引中的所有列进行匹配，必须按索引定义的顺序，比如：
b、匹配最左前缀
只使用索引的第一列
c、匹配列前缀
只使用索引的第一列
d、匹配值范围
只使用索引的第一列
e、精确匹配某一列并范围匹配另外一列
f、只访问索引的查询
B-Tree通常可以支持“只访问索引的查询”，即查询只需要访问索引，而无须访问数据行，这个在后面单独讨论这种“覆盖索引”的优化。
因为B-Tree是按顺序存储的，所以还可以用于查询中的排序操作order by，所以order by 如果满足前面列出的几种查询类型，则这个索引也可以满足对应的排序需求。
B-Tree索引的限制，无法用到索引的说明
a、不是按照最左列开始查找，则无法使用到索引。
当然dob字段也是一样的，即使是最左列也无法使用索引查找“%a”的格式
b、不能跳过中间的列，否则只能使用到索引的第一列
c、如果查询中有某个列的范围查询，则其右边的列无法使用索引优化，左边可以用到索引
这里显示都没有用到索引，是因为数据太少，可能引擎有自己的优化，增加数据到了1000条以上可以看看效果：可以看到的却查询影响的条数一样，的却是没有用到右侧的索引。
而实际的条数只有更少
所以，索引的顺序是很重要的，在优化性能的时候，可能需要使用相同的列但顺序不同的索引来满足不同类型的查询。
本文出自 “phper-每天一点点~” 博客，请务必保留此出处http://janephp.blog.51cto.com/4439680/1309667
