索引匹配方式
下面举例皆在索引 idx（name，age，pos）建立前提下
全值匹配
全值匹配指的是和索引中的所有列进行匹配
匹配最左前缀
只匹配前面的几列
匹配列前缀
可以匹配某一列的值的开头部分
比如：select * from staffs where name like ‘J%’;
这个语句可以利用到用name建立的索引进行查找。但是如果是 select * from staffs where name like ‘%J%’;就无法用到。
匹配范围值
可以查找某一个范围的数据
比如：explain select * from staffs where name > ‘Mary’;
精确匹配某一列并范围匹配另外一列
可以查询第一列的全部和第二列的部分
比如：explain select * from staffs where name = ‘July’ and age > 25;
只访问索引的查询
查询的时候只需要访问索引，不需要访问数据行，本质上就是覆盖索引
哈希索引
哈希索引是memory存储引擎使用的索引，memory的数据文件存储在内存中，这是它效率很高的原因，但正因如此memory不支持持久化，数据易丢失。
特点：
- 哈希索引基于哈希表的实现，只有精确匹配索引所有列的查询才有效（不只是范围查询）
- 在mysql中，只有memory的存储引擎显式支持哈希索引
- 哈希索引自身只需存储对应的hash值，所以索引的结构十分紧凑，这让哈希索引查找的速度非常快
限制/缺点：
- 哈希索引只包含哈希值和行指针，而不存储字段值，索引不能使用索引中的值来避免读取行
- 哈希索引数据并不是按照索引值顺序存储的，所以无法进行排序
- 哈希索引不支持部分列匹配查找，哈希索引是使用索引列的全部内容来计算哈希值
- 哈希索引支持等值比较查询，但不支持任何范围查询
- 访问哈希索引的数据非常快，除非有很多哈希冲突，当出现哈希冲突的时候，存储引擎必须遍历链表中的所有行指针，逐行进行比较，直到找到所有符合条件的行
- 哈希冲突比较多的话，维护的代价也会很高
组合索引
当包含多个列作为索引，需要注意的是正确的顺序依赖于该索引的查询，同时需要考虑如何更好的满足排序和分组的需要
案例：
注意倒数第二条语句，范围查找，后方的列不会再使用索引
聚簇索引与非聚簇索引
聚簇索引
不是单独的索引类型，而是一种数据存储方式，指的是数据行跟相邻的键值紧凑的存储在一起
优点：
- 可以把相关数据保存在一起
- 数据访问更快，因为索引和数据保存在同一个树中
- 使用覆盖索引扫描的查询可以直接使用页节点中的主键值
缺点：
- 聚簇数据最大限度地提高了IO密集型应用的性能，如果数据全部在内存，那么聚簇索引就没有什么优势
- 插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式（因此建议使用自增主键，每次插入新纪录都是追加，不涉及挪动其他记录，因此效率最高（性能），非主键索引占用的空间也最小（存储空间）。）
- 更新聚簇索引列的代价很高，因为会强制将每个被更新的行移动到新的位置
- 基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题
- 聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候
在MySQL中，B+树为了维护索引的有序性，在新插入值时会做必要的维护，常常需要逻辑上挪动后面的数据以腾出位置。
在挪动过程中，会出现页分裂与页合并。
页分裂：申请新的数据页，挪动部分数据从旧数据页到新数据页。
页合并：相邻两个页由于删除了数据，利用率很低之后，会将两个数据页合并。
非聚簇索引
数据文件跟索引文件分开存放
覆盖索引
- 如果一个索引包含所有需要查询的字段的值，我们称之为覆盖索引
- 不是所有类型的索引都可以称为覆盖索引，覆盖索引必须要存储索引列的值
- 不同的存储实现覆盖索引的方式不同，不是所有的引擎都支持覆盖索引，memory不支持覆盖索引
优点：
- 索引条目通常远小于数据行大小，如果只需要读取索引，那么mysql就会极大的减少数据访问量
- 因为索引是按照列值顺序存储的，所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少的多（符合磁盘预读特性）
- 一些存储引擎如MYISAM在内存中只缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用，这可能会导致严重的性能问题
- 由于INNODB的聚簇索引，覆盖索引对INNODB表优势很大
在执行计划中可以看到语句是否用到了覆盖索引：在explain的extra列可以看到using index的信息，此时就使用了覆盖索引，如下：
mysql> explain select store_id,film_id from inventory\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: inventory
partitions: NULL
type: index
possible_keys: NULL
key: idx_store_id_film_id
key_len: 3
ref: NULL
rows: 4581
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.01 sec)
在大多数存储引擎中，覆盖索引只能覆盖那些只访问索引中部分列的查询。不过，可以进一步的进行优化，可以使用innodb的二级索引来覆盖查询。
例如：actor使用innodb存储引擎，并在last_name字段又二级索引，虽然该索引的列不包括主键actor_id，但也能够用于对actor_id做覆盖查询