1.索引的类型
1) B-Tree索引
(1)概念
人们常说的Mysql索引一般是指B-Tree索引，它使用B-Tree数据结构来存储数据。存储引擎以不同的方式使用B-Tree索引，性能也各有不同，各有优劣。
MyISAM使用前缀压缩技术使得索引更小，但InnoDB则按照原数据格式进行存储。
MyISAM索引通过数据的物理位置引用被索引的行，而InnoDB则根据主键引用被索引的行。
B-Tree通常意味着所有的值都是按顺序存储的，并且每一个叶子页到根的距离相同。
下图展示了B-Tree索引的抽象表示，大致反映了InnoDB索引是如何工作的。MyISAM使用的结构有所不同，但基本思想是类似的。
B-Tree索引适用于全键值、键值范围或最左前缀查找。
(2)适用的查询类型：
（1）全值匹配：
全值匹配指的是和索引中的所有列进行匹配。
（2）匹配最左前缀
联合索引从最左列开始查找，若没有最左列索引，则无法使用索引。
（3）匹配列前缀
匹配某一列的值的开头部分（不能在开头使用“%”）
（4）匹配范围值
指匹配某个范围之间的值，如查找姓在1995-2000年出生的人
（5）精确匹配某一列并范围匹配另外一列
即“全值匹配”与“匹配范围值”的结合
（6）只访问索引的查询
B-Tree支持“只访问索引的查询”，即查询只需要访问索引，而无须访问数据行，这是就是常说的“覆盖索引”。
2）哈希索引
(1)概念
哈希索引基于哈希表实现，只有精确匹配索引所有列的查询才有效。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码，不同键值的行计算出来的哈希码也不一样（如果多个列的哈希值相同，索引会以链表的方式存放多个记录指针到同一个哈希条目中。原理和java中的HashMap类似）。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。
在MySQL中，只有Memory引擎显式支持哈希索引。这也是Memory引擎表的默认索引类型，Memory引擎同时也支持B-Tree索引。
(2)优点
因为索引自身只需存储对应的哈希值，所以索引的结构十分紧凑，这也让哈希索引查找的速度非常快。
(3)缺点
①哈希索引只包含哈希值和行指针，而不存储字段值，故没有“覆盖索引”的功能。
②哈希索引数据并不是按照索引值顺序存储的，无法用于排序。
③哈希索引始终是使用索引列的全部内容来计算哈希值的，哈希索引也不支持部分索引列匹配查找。
④哈希索引只支持等值比较查询，包括=、IN()、<=>（注意<>和<=>是不同的操作）。也不支持任何范围查询。
⑤当出现哈希冲突的时候，存储引擎必须遍历链表中所有的行指针，逐行进行比较，直到找到所有符合条件的行，查询速度会相对降低（相对B-TREE还是要快，除非哈希冲突十分严重）。如果哈希冲突很多的话，一些索引维护操作的代价也会很高。
3）空间索引（R-Tree）
MyISAM表支持空间索引，可以用作地理数据存储。和B-Tree索引不同，这类索引无须前缀查询。空间索引会从所有维度来索引数据。查询时，可以有效地使用任意维度来组合查询。必须使用MySQL的GIS相关函数如MBRCONTAINS()等来维护数据。
4）全文索引
全文索引是一种特殊类型的索引，它查找的是文本中的关键词，而不是直接比较索引中的值。全文搜索和其他几类索引的匹配方式完全不一样。它有许多需要注意的细节，如停用词、词干和复数、布尔搜索等。全文索引更类似于搜索引擎做的事情，而不是简单的WHERE条件匹配。（一般我们会选择专业的全文搜索引擎，如Solor、ElasticSearch等）
在相同的列上同时创建全文索引和基于值的B-Tree索引不会有冲突，全文索引适用于MATCH AGAINST操作，而不是普通的WHERE条件操作。
2.高效索引的创建与使用
1）独立的列
如果查询中的列不是独立的，则MySQL就不会使用索引。“独立的列”是指索引列不能是表达式的一部分，也不能是函数的参数。
下面的sql不会使用索引：
mysql> SELECT actor_id FROM sakila.actor WHERE actor_id 1 = 5;
2）前缀索引和索引选择性
通常可以索引开始的部分字符，这样可以大大节约索引空间，从而提高索引效率。但这样也会降低索引的选择性。索引的选择性是指，不重复的索引值（也称为基数，cardinality）和数据表的记录总数（#T）的比值，范围从1/#T到1之间。索引的选择性越高则查询效率越高，因为选择性高的索引可以让MySQL在查找时过滤掉更多的行。唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的。
一般情况下某个列前缀的选择性也是足够高的，足以满足查询性能。对于BLOB、TEXT或者很长的VARCHAR类型的列，必须使用前缀索引，因为MySQL不允许索引这些列的完整长度。
诀窍在于要选择足够长的前缀以保证较高的选择性，同时又不能太长（以便节约空间）。前缀应该足够长，以使得前缀索引的选择性接近于索引整个列。换句话说，前缀的“基数”应该接近于完整列的“基数”。
3）多列索引
在多个列上建立独立的单列索引大部分情况下并不能提高MySQL的查询性能，我们应集中精力优化索引列的顺序，或者创建一个全覆盖索引或联合索引
4）选择合适的索引列顺序
在一个多列B-Tree索引中，索引列的顺序意味着索引首先按照最左列进行排序，其次是第二列，等等。
选择索引的列顺序有一个经验法则：将选择性最高的列放到索引最前列
5）聚簇索引
(1)概念
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。具体的细节依赖于其实现方式，但InnoDB的聚簇索引实际上在同一个结构中保存了B-Tree索引和数据行。当表有聚簇索引时，它的数据行实际上存放在索引的叶子页中。术语“聚 簇”表示数据行和相邻的键值紧凑地存储在一起因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。
因为是存储引擎负责实现索引，因此不是所有的存储引擎都支持聚簇索引。本节我们主要关注InnoDB，但是这里讨论的原理对于任何支持聚簇索引的存储引擎都是适用的。
下图展示了聚簇索引中的记录是如何存放的。注意到，叶子页包含了行的全部数据，但是节点页只包含了索引列。在这个案例中，索引列包含的是整数值。
InnoDB将通过主键聚集数据，这也就是说上图中的“被索引的列”就是主键列。如果没有定义主键，InnoDB会选择一个唯一的非空索引代替。如果没有这样的索引，InnoDB会隐式定义一个主键来作为聚簇索引。InnoDB只聚集在同一个页面中的记录。包含相邻键值的页面可能会相距甚远。
聚簇主键可能对性能有帮助，但也可能导致严重的性能问题。所以需要仔细地考虑聚簇索引，尤其是将表的存储引擎从InnoDB改成其他引擎的时候。
(2)优点
①可以把相关数据保存在一起。例如实现电子邮箱时，可以根据用户ID来聚集数据， 这样只需要从磁盘读取少数的数据页就能获取某个用户的全部邮件。如果没有使用聚簇索引，则每封邮件都可能导致一次磁盘I/O。
②数据访问更快。聚簇索引将索引和数据保存在同一个B-Tree中，因此从聚簇索引中获取数据通常比在非聚簇索引中查找要快。
③使用覆盖索引扫描的查询可以直接使用页节点中的主键值。
(3)缺点
①聚簇数据最大限度地提高了I/O密集型应用的性能，但如果数据全部都放在内存中， 则访问的顺序就没那么重要了，聚簇索引也就没什么优势了。
②插入速度严重依赖于插入顺序。按照主键的顺序插入是加载数据到InnoDB表中速度最快的方式。但如果不是按照主键顺序加载数据，那么在加载完成后最好使用OPTIMIZE TABLE命令重新组织一下表。
③更新聚簇索引列的代价很高，因为会强制InnoDB将每个被更新的行移动到新的位置。
④基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临“页分裂（page split）”的问题。当行的主键值要求必须将这一行插入到某个已满的页中时，存储引擎会将该页分裂成两个页面来容纳该行，这就是一次页分裂操作。页分裂会导致表占用更多的磁盘空间。
⑤聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候。
⑥二级索引（非聚簇索引）可能比想象的要更大，因为在二级索引的叶子节点包含了引用行的主键列。
⑦二级索引访问需要两次索引查找，而不是一次。
6) 覆盖索引
如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为“覆盖索引”。覆盖索引在查询时只需要扫描索引而无须回表，能够极大地提高性能。
7)使用索引扫描来做排序
MySQL有两种方式可以生成有序的结果：通过排序操作；或者按索引顺序扫描； 如果EXPLAIN出来的type列的值为“index”，则说明MySQL使用了索引扫描来做排序（不要和Extra列的“Using index”搞混淆了）。
扫描索引本身是很快的，因为只需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列，那就不得不每扫描一条索引记录就都回表查询一次对应的行。
8)压缩（前缀压缩）索引
MyISAM使用前缀压缩来减少索引的大小，从而让更多的索引可以放入内存中，这在某些情况下能极大地提高性能。默认只压缩字符串，但通过参数设置也可以对整数做压 缩。MyISAM压缩每个索引块的方法是，先完全保存索引块中的第一个值，然后将其他值和第一个值进行比较得到相同前缀的字节数和剩余的不同后缀部分，把这部分存储起来即可。例如，索引块中的第一个值是“perform”，第二个值是“performance”，那么第二个值的前缀压缩后存储的是类似“7,ance”这样的形式。MyISAM对行指针也采用类似的前缀压缩方式。
9)冗余和重复索引
MySQL允许在相同列上创建多个索引，无论是有意的还是无意的。MySQL需要单独维护重复的索引，并且优化器在优化查询的时候也需要逐个地进行考虑，这会影响性能。
重复索引是指在相同的列上按照相同的顺序创建的相同类型的索引。应该避免这样创建重复索引，发现以后也应该立即移除。
10)未使用的索引
除了冗余索引和重复索引，可能还会有一些服务器永远不用的索引。这样的索引完全是累赘，建议考虑删除。
11)索引和锁
索引可以让查询锁定更少的行。如果你的查询从不访问那些不需要的行，那么就会锁定更少的行，从两个方面来看这对性能都有好处。首先，虽然InnoDB的行锁效率很高， 内存使用也很少，但是锁定行的时候仍然会带来额外开销；其次，锁定超过需要的行会增加锁争用并减少并发性。
InnoDB只有在访问行的时候才会对其加锁，而索引能够减少InnoDB访问的行数，从而减少锁的数量。但这只有当InnoDB在存储引擎层能够过滤掉所有不需要的行时才有 效。如果索引无法过滤掉无效的行，那么在InnoDB检索到数据并返回给服务器层以后，MySQL服务器才能应用WHERE子句。这时已经无法避免锁定行了：InnoDB已经锁住了这些行，到适当的时候才释放。