一、索引的类型

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条以上可以看看效果：可以看到的却查询影响的条数一样，的却是没有用到右侧的索引。

而实际的条数只有更少

所以，索引的顺序是很重要的，在优化性能的时候，可能需要使用相同的列但顺序不同的索引来满足不同类型的查询。