索引类型

B-Tree 索引

先来说说 MyISAM 和 InnoDB 索引的简单区别。
MyISAM 使用的前缀压缩技术使得索引更小，InnoDB 则按照原数据格式进行存储。MyISAM 索引通过数据的物理位置引用被索引的行，而 InnoDB 则根据主键引用被索引的行。

image.png

B-Tree 索引能够快速方位数据，不需要进行全表扫描，从索引的根节点开始进行搜索。存储引擎通过指向叶子节点的指针向下一层查找。

可以使用 B-Tree 索引查询类型 B-Tree 索引适用于全键值、键值范围或者键前缀查找。
全值匹配
全值匹配指的是和索引中的所有列进行匹配。
匹配最左前缀
只使用索引的第一列。
匹配列前缀
也可以只匹配某一列的值的开头部分。
匹配范围值
查找在 xxx 和 xxx 之间，这里也使用了索引的第一列。
精确匹配某一列并范围匹配另外一列
可以查找 姓名为 Allen 并且是字母 K 开头的人。
只访问索引的查询
查询只需要访问索引，不需要方位数据行。

关于 B-Tree 索引的限制：

如果不是按照最左列开始查找就无法使用索引；
不能跳过索引中的列；
如果查询中有某个列的范围查询，则其右边的所有列都无法使用索引优化查找。

哈希索引

只有精确匹配索引所有列的查询才有效，Memory 引擎显示支持哈希索引。

哈希索引只包含哈希值和行指针不储存字段值。
哈希索引也不支持部分索引列匹配查找。
哈希索引数据并不是按照索引值顺序存储的，也就无法进行排序。
哈希索引只支持等值比较查询。
访问哈希索引的数据非常快。

InnoDB 没有哈希索引，但是有一个特殊功能叫做“自适应哈希索引” 它会在内存中基于 B-Tree 索引之上再创建一个哈希索引。需要触发器来维护哈希值。
在数据量非常庞大的时候，需要增加服务器倒数据的时候，还可以用一致性哈希。
关于一致性哈希和应用看这个链接：
https://www.cnblogs.com/lpfuture/p/5796398.html
https://blog.csdn.net/xiaobluesky/article/details/50429428

全文索引

它查找的是文本中的关键词，适用于 MATCH AGAINST 操作。

索引的优点

索引大大减少了服务器需要扫描的数据量
索引可以帮助服务器避免排序和临时表
索引可以将随机 I/O 变为顺序 I/O。

高性能的索引策略

如果查询中的列不是独立的，MySQL 就不会使用索引。
简化Where 条件的习惯，始终将索引列单独放在比较符号的一侧。

有时候要索引很长的字符列，这会让索引变得大且慢，可以索引开始的部分字符，大大节约索引时间，但是会降低选择性。
创建前缀索引是一种能使索引更小更快的办法，但是MySQL无法使用前缀索引做 ORDER BY 和 GROUP BY。也无法使用前缀索引做覆盖扫描。

多列索引

MySQL 5.0 引入了一种叫“索引合并”的策略，查询能够同时使用两个单列的索引进行扫描，并将结果进行合并。通过 EXPLAIN 和 Extra 列可以看到这点
但是这种一般说明索引建的很糟糕。

选择合适的索引列顺序

索引列顺序意味着索引首先按照最左列进行排序，其次第二列，所以多列索引的列顺序至关重要。
可以根据选择性最高的列放在前面，但是不如避免随机 I/O 和排序那么重要，但是通常是好的选择。

聚簇索引

聚簇索引表示数据行和相邻的键值紧凑地储存在一起。
优点：
可以把相关的数据保存在一起；
数据访问更快；
使用覆盖索引扫描的查询可以直接使用页节点中的主键值。

缺点：
聚簇索引最大限度的提高了 I/O 密集型的应用性能。但是如果数据全部存放在内存中，则访问顺序就没那么重要了；
插入速度严重依赖于插入顺序；
更新聚簇索引列的代价很高；
插入新行可能存在“页分裂”的问题；
聚簇索引可能导致全表扫描变慢；
二级索引可能比想象要更大，二级索引访问需要两次索引查找。

覆盖索引

如果一个索引包含（或者覆盖）所有要查询的字段的值，我们就称之为“覆盖索引”。
索引条目远小于数据行大小。
对 I/O 密集型范围查询会比随机少很多。
对于 InnoDB 避免主键索引的二次查询。