MySQL调优之索引匹配方式及索引种类

索引匹配方式

下面举例皆在索引 idx（name，age，pos）建立前提下

全值匹配

全值匹配指的是和索引中的所有列进行匹配

匹配最左前缀

只匹配前面的几列

匹配列前缀

可以匹配某一列的值的开头部分

比如：select * from staffs where name like ‘J%’;
这个语句可以利用到用name建立的索引进行查找。但是如果是 select * from staffs where name like ‘%J%’;就无法用到。

匹配范围值

可以查找某一个范围的数据

比如：explain select * from staffs where name > ‘Mary’;

精确匹配某一列并范围匹配另外一列

可以查询第一列的全部和第二列的部分

比如：explain select * from staffs where name = ‘July’ and age > 25;

只访问索引的查询

查询的时候只需要访问索引，不需要访问数据行，本质上就是覆盖索引

哈希索引

哈希索引是memory存储引擎使用的索引，memory的数据文件存储在内存中，这是它效率很高的原因，但正因如此memory不支持持久化，数据易丢失。

特点：

• 哈希索引基于哈希表的实现，只有精确匹配索引所有列的查询才有效（不只是范围查询）
• 在mysql中，只有memory的存储引擎显式支持哈希索引
• 哈希索引自身只需存储对应的hash值，所以索引的结构十分紧凑，这让哈希索引查找的速度非常快

限制/缺点：

• 哈希索引只包含哈希值和行指针，而不存储字段值，索引不能使用索引中的值来避免读取行
• 哈希索引数据并不是按照索引值顺序存储的，所以无法进行排序
• 哈希索引不支持部分列匹配查找，哈希索引是使用索引列的全部内容来计算哈希值
• 哈希索引支持等值比较查询，但不支持任何范围查询
• 访问哈希索引的数据非常快，除非有很多哈希冲突，当出现哈希冲突的时候，存储引擎必须遍历链表中的所有行指针，逐行进行比较，直到找到所有符合条件的行
• 哈希冲突比较多的话，维护的代价也会很高

组合索引

当包含多个列作为索引，需要注意的是正确的顺序依赖于该索引的查询，同时需要考虑如何更好的满足排序和分组的需要

案例：

注意倒数第二条语句，范围查找，后方的列不会再使用索引

聚簇索引与非聚簇索引

聚簇索引

不是单独的索引类型，而是一种数据存储方式，指的是数据行跟相邻的键值紧凑的存储在一起

优点：

• 可以把相关数据保存在一起
• 数据访问更快，因为索引和数据保存在同一个树中
• 使用覆盖索引扫描的查询可以直接使用页节点中的主键值

缺点：

• 聚簇数据最大限度地提高了IO密集型应用的性能，如果数据全部在内存，那么聚簇索引就没有什么优势
• 插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式（因此建议使用自增主键，每次插入新纪录都是追加，不涉及挪动其他记录，因此效率最高（性能），非主键索引占用的空间也最小（存储空间）。）
• 更新聚簇索引列的代价很高，因为会强制将每个被更新的行移动到新的位置
• 基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题
• 聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候

在MySQL中，B+树为了维护索引的有序性，在新插入值时会做必要的维护，常常需要逻辑上挪动后面的数据以腾出位置。

在挪动过程中，会出现页分裂与页合并。

页分裂：申请新的数据页，挪动部分数据从旧数据页到新数据页。

页合并：相邻两个页由于删除了数据，利用率很低之后，会将两个数据页合并。

非聚簇索引

数据文件跟索引文件分开存放

覆盖索引

• 如果一个索引包含所有需要查询的字段的值，我们称之为覆盖索引
• 不是所有类型的索引都可以称为覆盖索引，覆盖索引必须要存储索引列的值
• 不同的存储实现覆盖索引的方式不同，不是所有的引擎都支持覆盖索引，memory不支持覆盖索引

优点：

1. 索引条目通常远小于数据行大小，如果只需要读取索引，那么mysql就会极大的减少数据访问量
2. 因为索引是按照列值顺序存储的，所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少的多（符合磁盘预读特性）
3. 一些存储引擎如MYISAM在内存中只缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用，这可能会导致严重的性能问题
4. 由于INNODB的聚簇索引，覆盖索引对INNODB表优势很大

在执行计划中可以看到语句是否用到了覆盖索引：在explain的extra列可以看到using index的信息，此时就使用了覆盖索引，如下：

mysql> explain select store_id,film_id from inventory\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: inventory
   partitions: NULL
         type: index
possible_keys: NULL
          key: idx_store_id_film_id
      key_len: 3
          ref: NULL
         rows: 4581
     filtered: 100.00
        Extra: Using index
1 row in set, 1 warning (0.01 sec)

在大多数存储引擎中，覆盖索引只能覆盖那些只访问索引中部分列的查询。不过，可以进一步的进行优化，可以使用innodb的二级索引来覆盖查询。

例如：actor使用innodb存储引擎，并在last_name字段又二级索引，虽然该索引的列不包括主键actor_id，但也能够用于对actor_id做覆盖查询