[MySQL-笔记]创建高性能索引

Posted 2020-09-07 wilderness

　　索引，mysql中也叫“键”，是存储引擎中用于快速找到记录的一种数据结构，具体的工作方式就像书本中的索引一样，但是具体的实现方式会有差别。

一.索引分类

B-Tree索引：

　　优点：

• MyISAM中，索引根据数据的物理位置引用被索引的行，InnoDB中根据主键引用被索引的行。
• B-Tree索引能够加快访问数据的速度，因为存储引擎不再需要进行全表扫描来获取需要的数据，而是从索引的根节点开始进行搜索。
• B-Tree对索引列是顺序组织存储的，所以很适合查找范围数据。
• 一般来说，B-Tree可以按照某种方式查找到值，那么也可以用这种方式排序

　　限制：

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

哈希索引：

　　哈希索引基于哈希表实现，只有精确匹配的索引所有列的查询才有效

　　优点：

• 非常快

　　限制：

• 哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。
• 哈希索引不是按照索引值顺序存储的，所以不能用于排序。
• 哈希索引不支持部分索引列匹配查找。
• 哈希索引只支持等值比较查询。
• 哈希冲突很多的话，一些索引维护操作的代价会很高。

二.索引的优点

最常见的是B-Tree索引，按照顺序存储数据，所以可以用来做ORDER BY和GROUP BY操作。因为数据是有次序的，所以B-Tree也就会将相关的列值存储在一块。由于索引中存储了实际的列值，所以某些查询只使用索引就可以完成全部查询。

1.索引大大减少了服务器需要扫描的数据量

2.索引可以帮助服务器避免排序和临时表

3.索引可以将随机I/O变为顺序I/O.

 

三.高性能索引策略

1） 独立的列

独立的列是指索引列不能是表达式的一部分，也不能是函数的一部分

2）前缀索引和索引选择性

诀窍在于要选择足够长的索引以保证高的索引选择性，但是又不能太长（节约空间）。

3）多列索引

首先“把where条件里面的列都建上索引”是错误的。

如果在一个查询用使用两个单列索引，在老版本的MySQL中会导致全表扫描，在新版本中，查询可以使用多个单列索引，并将结果合并。

这种算法有三个变种：

• 　　　OR条件的联合（union）
• 　　　AND条件的相交（intersection）
• 　　　以前OR和AND的组合

索引合并策略更多的说明了索引建的很糟糕：

• 当出现服务器对多个索引做相交操作时，通常意味着需要一个包含所有相关列的多列索引，而不是多个独立的单列索引
• 当服务器需要对多个索引做联合操作时，通常需要耗费大量的CPU和内存资源在算法的缓存/排序/合并操作上。

4）选择合适的索引列顺序

　　多列索引的顺序至关重要

　　有一个经验法则：当不需要考虑排序和分组时候，将选择性高的列放在前面通常是很好的。

 

5) 聚簇索引

　　聚簇索引不是一种单独的索引类型，而是一种数据存储方式，实际上，InnoDB聚簇索引在同一个结构中保存了B-Tree索引和数据行。当表有聚簇索引时候，它的数据行实际上放在索引的叶子页中。“聚簇”，表示数据行和键值紧凑的存储再一起。

　　优点：

• 可以把相关数据保存在一起，减少磁盘I/O
• 数据访问更快，因为索引和数据保存在同一个B-Tree中
• 使用覆盖索引扫描查询可以直接使用页节点的主键值。

　　缺点：

• 聚簇索引最大限度的提高了I/O密集型应用的性能，但是如果数据都在内存中，聚簇索引就没有优势了
• 插入速度严重依赖插入顺序
• 更新聚簇索引代价很高
• 在插入新行，或者主键更新需要移动行时候，可能导致页分裂。
• 导致全表扫描变慢，尤其是行稀疏的时候，或者由于页分裂导致数据存储不连续时候
• 二级所以可能比想象中更大，因为二级索引的叶子节点包含了主键值
• 二级索引访问需要两次索引查找，而不是一次。

6）覆盖索引

如果一个索引包含（覆盖）了所有需要查询的字段的值，那么就是覆盖索引

覆盖索引必须要存储索引列的值，而哈希索引，空间索引，全文索引都不存储索引列的值，只有B-Tree可以

MySQL不能再索引中执行LIKE操作，这是底层API的限制，MySQL只能提取数据行的值而不是索引的值来比较。

为了利用覆盖索引，我们可以利用一种叫延迟关联的技巧

7） 使用索引扫描来做排序

 

参考资料：高性能MySQL第五章