索引，在MySQL中也叫作“键(key)”，是存储引擎用于快速找到记录的一种数据结构。索引对于良好的性能非常关键。
譬如 mysql> select first_name from sakila.actor where actor_id = 5;
如果在actor_id列上建有索引，则MySQL将使用该索引找到actor_id为5的行，也就是说，MySQL先在索引上按值进行查找，然后返回所有包含该值的数据行。
索引可以包含一个或多个列的值。如果索引包含多个列，那么列的顺序也十分重要，因为MySQL只能高效地使用索引的最左前缀列。
索引有很多种类型，可以为不同的场景提供更好的性能。在MySQL中，索引是在存储引擎层而不是服务器层实现的。所以并没有统一的索引标准：不同存储引擎的索引的工作方式并不一样，也不是所有的存储引擎都支持所有类型的索引。即使多个存储引擎支持同一种类型的索引，其底层的实现也可能不同。
下面我们来看看mysql支持的索引类型，以及它们的优缺点：
- B+Tree索引
- 哈希索引
- 空间数据索引
- 全文索引
1.B+Tree索引：
它使用B+Tree数据结构来存储数据，大多数MySQL引擎都支持这种索引。
存储引擎以不同的方式使用B+Tree索引，性能也各有不同，各有优劣。
| 引擎 | InnoDB | MyISAM |
| 索引存储方式 | 原数据格式存储 | 前缀压缩技术使得索引更小 |
| 引用被索引的行方式 | 根据主键引用被索引的行 | 通过数据的物理位置引用被索引的行 |
B+Tree通常意味着所有的值都是按照顺序存储的，并且每一个叶子页到根的距离相同。
B+Tree索引能够加快访问数据的速度，因为存储引擎不再需要进行全表扫描来获取需要的数据，取而代之的是从索引的根节点开始进行搜索。根节点的槽中存放了指向子节点的指针，存储引擎根据这些指针向下层查找。通过比较节点页的值和要查找的值可以找到合适的指针进入下层子节点，这些指针实际上定义了子节点页中值的上限和下限。最终存储引擎要么是找到对应的值，要么该记录不存在。
叶子节点比较特别，它们的指针指向的是被索引的数据，而不是其他的节点页。
树的深度和表的大小直接相关。
B+Tree对索引列是顺序组织存储的，所以很适合查找范围数据。
B+Tree索引适用于全键值、键值范围或键前缀查找。其中键前缀查找只试用于根据最左前缀的查找。前面所述的索引对如下类型的查询有效：
| 查询类型 | 说明 |
| 全值匹配 | ... |
| 匹配最左前缀 | ... |
| 匹配列前缀 | ... |
| 匹配范围值 | ... |
| 精确匹配某一列并范围匹配另外一列 | ... |
| 只访问索引的查询 | ... |
因为索引树中的节点是有序的，所以除了按值查找之外，索引还可以用于查询中的order by操作。一般来说，如果B+Tree可以按照某种方式查找到值，那么也可以按照这种方式用于排序。所以如果order by子句满足前面列出的几种查询类型，则这个索引也可以满足对应的排序需求。
下面是一些关于B+Tree索引的限制：
- 如果不是按照索引的最左列开始查找，则无法使用索引。
- 不能跳过索引中的列。
- 如果查询中有某个列的范围，则其右边所有列都无法使用索引优化查找。
2.哈希索引：
在MySQL中，只有Memory引擎显式支持哈希索引。这也是Memory引擎表的默认索引类型。
InnoDB引擎有一个特殊的功能叫作“自适应哈希索引”。当InnoDB注意到某些索引值被使用得非常频繁时，它会在内存中基于B+Tree索引之上再创建一个哈希索引，这就让B+Tree索引也具有哈希索引的一些优点，比如快速的哈希查找。这是一个完全自动的、内部的行为，用户无法控制或配置，不过如果有必要，完全可以关闭该功能。
3.空间数据索引：
MyISAM表支持空间索引，可以用作地理数据存储。和B+Tree索引不同，这类索引无须前缀查询。空间索引会从所有维度来索引数据。查询时，可以有效地使用任意维度来组合查询。必须使用MySQL的GIS相关函数如MBRCONTAINS( )等来维护数据。MySQL的GIS支持并不完善，所以大部分人都不会使用这个特性。开源关系数据库系统中对GIS的解决方案做得比较好的是PostgreSQL的PostGIS。
4.全文索引：
全文索引类似于搜索引擎做的事情，而不是简单的WHERE条件匹配。