索引基础
索引是存储引擎用于快速找到记录的一种数据结构。索引能轻易将查询性能提高几个数量级。索引可以包含一个或多个列的值。如果索引包含多个列，那么列的顺序也十分重要，因为 MySQL 只能高效地使用索引的最左前缀列。
索引的类型
- B-TREE 索引：使用 B-Tree 数据结构。大多数 MySQL 引擎都支持这种索引。不过底层的存储引擎也可能使用不同的存储结构。InnoDB 使用的是B+Tree。B-Tree 索引适用于**全键值、键值范围或键前缀查找（最左前缀）。B-TREE 索引的一些限制：1.如果不是按照索引的最左列开始查找，则无法使用索引。2.不能跳过索引中的列。3.如果查询中有某个列的范围查询，则其右边所有列都无法使用索引优化查找。
- 哈希索引：基于哈希表实现，只有精确匹配索引所有列的查询才有效。只有Memory引擎显式支持哈希索引。
索引的优点
- 索引大大减少了服务器需要扫描的数据量。
- 索引可以帮助服务器避免排序和临时表。
- 索引可以将随机 I/O 变为顺序 I/O。
高性能的索引策略
独立的列
索引列不能是表达式的一部分，也不能是函数的参数。
前缀索引和索引选择性
有时候需要索引很长的字符列，这会让索引变得大且慢。这种情况下可以索引开始的部分字符，这样可以大大节约索引空间，从而提高索引效率。但这样也会降低索引的选择性。索引的选择性是指，不重复的索引值和数据表的记录总数的比值。索引的选择性越高则查询效率越高，因为选择性高的索引可以让 MySQL 在查找时过滤掉更多的行。
前缀索引是一种能使索引更小、更快的有效办法，但也有缺点：MySQL 无法使用前缀索引做 ORDER BY 和 GROUP BY，也无法使用前缀索引做覆盖扫描。
多列索引
在多个列上建立独立的单列索引大部分情况下并不能提高 MySQL 的查询性能。索引合并策略（index merge），在一定程度上可以使用表上的多个单列索引来定位指定的行，但更多时候说明来表上的索引建的很糟糕。
选择合适的索引列顺序
正确的顺序依赖于使用该索引的查询，并且同时需要考虑如何更好地满足排序和分组的需要。
聚簇索引
聚簇索引不是一种单独的索引类型，而是一种数据存储方式。InnoDB的聚簇索引实际上在同一个结构中保存了 B-Tree 索引和数据行。数据行实际上存放在索引的叶子节点中。因为无法同时把数据行放在两个不同的地方，所以一个表只能有一个聚簇索引（覆盖索引可以模拟多个聚簇索引的情况）。InnoDB通过主键聚集数据，如果没有主键，InnoDB会选择一个唯一的非空索引代替。如果没有这样的索引，则隐式定义一个主键来作为聚簇索引。
聚簇索引优点：
- 可以把相关数据保存在一起，减少磁盘I/O。
- 数据访问更快。
- 使用覆盖索引扫描的查询可以直接使用页节点的主键值。
聚簇索引缺点：
- 如果数据全部放在内存中，则聚簇索引没什么优势来。
- 插入速度严重依赖于插入顺序。按照主键的顺序插入是速度最快的方式。
- 更新聚簇索引的代价很高。
- 在插入新行或主键被更新导致需要移动行的时候，可能面临页分裂的问题。
- 可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续。
- 二级索引占用了更多空间，因为二级索引的叶子节点包含了引用行的主键。
- 二级索引访问需要两次索引查找。
覆盖索引
如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为“覆盖索引”。
覆盖索引的好处：
- 索引条目通常远小于数据行大小
- 简单的范围查询能使用完全顺序的索引访问。
- InnoDB的二级索引如果能够覆盖查询，则可以避免对主键索引的二次查询。
使用索引扫描做排序
MySQL 有两种方式可以生成有序的结果：通过排序操作或者按索引顺序扫描。只有当索引的列顺序和 ORDER BY 字句的顺序完全一致，并且所有列的排序方向都一样时，MySQL 才能够使用索引来对结果做排序。如果查询需要关联多张表，则只有当 ORDER BY 字句引用的字段全部为第一个表时，才能使用索引做排序。
索引和锁
索引可以让查询锁定更少的行。InnoDB 只有在访问行的时候才会对其加锁，而索引能够减少InnoDB访问的行数，从而减少锁的数量。但这只有当 InnoDB 在存储引擎层能够过滤掉所有不需要的行时才有效。
