MySQL通过索引优化-这里可能有你不知道的索引优化细节（一）

我在 MySQL优化必备之执行计划explain，索引基本知识，索引数据结构推演里，提到了索引的一些基本概念，提到MySQL优化，很多人第一时间会想到建索引。

通过索引优化，具体该怎么做，有哪些细节？

哈希索引

在MySQL中，只有memory的存储引擎显式支持哈希索引。

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

哈希索引自身只需存储对应的hash值，所以索引的结构十分紧凑，这让哈希索引查找的速度非常快。

哈希索引的限制

哈希索引只包含
```
哈希值
```
和
```
行指针
```
，而不存储
```
字段值
```
，所以不能使用索引中的值来避免读取行
哈希索引数据并不是按照索引值顺序存储的，所以无法进行排序
哈希索引不支持部分列匹配查找，哈希索引是使用索引列的全部内容来计算哈希值
它们仅用于使用
```
=
```
或
```
<=>
```
运算符的相等比较（但非常快）。
它们不用于比较运算符（例如
```
<
```
）来查找值的范围。
访问哈希索引的数据非常快，除非有很多哈希冲突，当出现哈希冲突的时候，存储引擎必须遍历链表中的所有行指针，逐行进行比较，直到找到所有符合条件的行

哈希（Hash）一般叫做散列，意思就是把一堆任意长度的字符串、数字或者二进制输入通过一定的算法（非常多的哈希算法）生成固定长度的一个数字（字符串）。因为算法原因，不同的输入就会得到不同的哈希值。

哈希表（Hash Table）一般叫做散列表，就是通过把键值计算出Hash值后，通过Hash值映射到表里面的某个位置。那么同样的键值，下次访问或者修改都是同一个映射位置，不同的键值因为计算出Hash值不一样映射的位置也会不同。

因为哈希值是通过一定算法生成的，那么就有一定的
可能出现不同的输入得到的Hash值是一样的
，就算我们可以通过调整算法尽量减少这种情况，但是也不可完全避免。发生这种情况后，我们就会出现两个不同的键值被映射到同一个位置了，这就是
哈希冲突
。

哈希冲突比较多的话，维护的代价也会很高

哈希索引使用案例

当需要存储大量的URL，并且根据URL进行搜索查找，如果使用B+树，存储的内容就会很大（比如URL超长的情况）：

select id from url where url=\'\'

也可以利用将url使用CRC32做哈希，可以使用以下查询方式：

select id fom url where url=\'\' and url_crc=CRC32(\'\')

此查询性能较高原因是使用体积很小的索引来完成查找

组合索引

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

假设有个表建了索引(a, b, c)，那么不同SQL语句使用索引的情况如下：

查询条件	组合索引是否发挥作用
where a=3	是，只使用了a
where a=3 and b=5	是，使用了a,b
where a=3 and b=5 and c=6	是，使用了a,b,c
where a=3 and b=5	是，使用了a,b
where b=3 or c=5	否
where a=3 and c=6	是，只使用了a
where a=3 and b<10 and c=7	是，使用了a,b
where a=3 and b like ‘%xxoo%’ and c=7	是，只是用了a

组合索引使用案例

建表：

create table staffs(id int primary key auto_increment,name varchar(24) not null default \'\' comment \'姓名\',age int not null default 0 comment \'年龄\',pos varchar(20) not null default \'\' comment \'职位\',add_time timestamp not null default current_timestamp comment \'入职时间\') charset utf8 comment \'员工记录表\';

建一个组合索引：

alter table staffs add index idx_nap(name, age, pos);

使用name,age,pos三个字段做查询条件，并且顺序按照组合索引顺序：

mysql> explain select * from staffs where name=\'zhangsan\' and age=18 and pos=\'programmer\'\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: staffspartitions: NULLtype: refpossible_keys: idx_napkey: idx_napkey_len: 140ref: const,const,constrows: 1filtered: 100.00Extra: NULL1 row in set, 1 warning (0.01 sec)

该查询用到了索引
idx_nap
，
type
为
ref
，并且ref为
const,const,const
。这种是最理想的条件。

使用name,age,pos三个字段做查询条件，并且顺序按照组合索引顺序，但是age使用了范围查询：

mysql> explain select * from staffs where name=\'zhangsan\' and age>18 and pos=\'programmer\'\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: staffspartitions: NULLtype: rangepossible_keys: idx_napkey: idx_napkey_len: 78ref: NULLrows: 1filtered: 100.00Extra: Using index condition1 row in set, 1 warning (0.01 sec)

该查询的也用到了索引
idx_nap
，但
type
为
range
，我们知道
range
的查询效率要低于
ref
的。原因是该查询只用到了
name
和
age
两个索引，组合索引的
pos
字段没有用上。

查询条件只用到组合索引的后两个字段

mysql> explain select * from staffs where age=18 and pos=\'programmer\'\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: staffspartitions: NULLtype: ALLpossible_keys: NULLkey: NULLkey_len: NULLref: NULLrows: 1filtered: 100.00Extra: Using where1 row in set, 1 warning (0.00 sec)

这个
type
就是
ALL
了，这种情况索引是失效的，没有用到索引，效率是最低的。

聚簇索引与非聚簇索引

聚簇索引

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

InnoDB的存储方式就是聚簇索引，索引和值放在同一个文件,
.ibd
文件。

聚簇索引的优点

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

聚簇索引的缺点

聚簇数据最大限度地提高了IO密集型应用的性能，如果数据全部在内存，那么聚簇索引就没有什么优势
插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式
更新聚簇索引列的代价很高，因为会强制将每个被更新的行移动到新的位置
基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题
聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候

非聚簇索引

数据文件和索引文件分开存放，MyIsam存储引擎就是如此。

覆盖索引

如果一个索引包含所有需要查询的字段的值，我们称之为覆盖索引，比如这个：

select name,age,pos from staffs where name=\'zhangsan\' and age=18 and pos=\'programmer\';

不是所有类型的索引都可以称为覆盖索引，覆盖索引必须要存储索引列的值。

不同的存储实现覆盖索引的方式不同，不是所有的引擎都支持覆盖索引，memory不支持覆盖索引。

覆盖索引有哪些好处

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

案例

MySQL官网上很贴心的给出了一些示例，并且很贴心的建了一些表供我们使用，我很感动的说！！！

比如MySQL提供的

sakila

数据库：

我们可以从这里获取：

下载下来之后我们导入本地进行测试：

mysql> source /root/soft/sakila-schema.sqlmysql> source /root/soft/sakila-data.sql

好了，可以愉快地使用这些表了。

当发起一个被索引覆盖的查询时，在
```
explain
```
的
```
extra
```
列可以看到
```
using index
```
的信息，此时就使用了覆盖索引

mysql> explain select store_id,film_id from inventory\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: inventorypartitions: NULLtype: indexpossible_keys: NULLkey: idx_store_id_film_idkey_len: 3ref: NULLrows: 4581filtered: 100.00Extra: Using index1 row in set, 1 warning (0.00 sec)

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

例如

actor

表：

mysql> desc actor;+-------------+----------------------+------+-----+-------------------+-----------------------------+| Field       | Type                 | Null | Key | Default           | Extra                       |+-------------+----------------------+------+-----+-------------------+-----------------------------+| actor_id    | smallint(5) unsigned | NO   | PRI | NULL              | auto_increment              || first_name  | varchar(45)          | NO   |     | NULL              |                             || last_name   | varchar(45)          | NO   | MUL | NULL              |                             || last_update | timestamp            | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |+-------------+----------------------+------+-----+-------------------+-----------------------------+4 rows in set (0.00 sec)

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

mysql> explain select actor_id,last_name from actor where last_name=\'HOPPER\'\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: actorpartitions: NULLtype: refpossible_keys: idx_actor_last_namekey: idx_actor_last_namekey_len: 182ref: constrows: 2filtered: 100.00Extra: Using index1 row in set, 1 warning (0.00 sec)

通过索引优化的一些细节

1. 当使用索引列进行查询的时候尽量不要使用表达式，把计算放到业务层而不是数据库层

看一个案例：

mysql> select actor_id from actor where actor_id=4;+----------+| actor_id |+----------+|        4 |+----------+1 row in set (0.00 sec)mysql> select actor_id from actor where actor_id+1=5;+----------+| actor_id |+----------+|        4 |+----------+1 row in set (0.02 sec)

第一条语句和第二条语句查询结果是一样的，但是执行效率是有差别的：

mysql> explain select actor_id from actor where actor_id=4;+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra       |+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+|  1 | SIMPLE      | actor | NULL       | const | PRIMARY       | PRIMARY | 2       | const |    1 |   100.00 | Using index |+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------------+1 row in set, 1 warning (0.00 sec)mysql> explain select actor_id from actor where actor_id+1=4;+----+-------------+-------+------------+-------+---------------+---------------------+---------+------+------+----------+--------------------------+| id | select_type | table | partitions | type  | possible_keys | key                 | key_len | ref  | rows | filtered | Extra                    |+----+-------------+-------+------------+-------+---------------+---------------------+---------+------+------+----------+--------------------------+|  1 | SIMPLE      | actor | NULL       | index | NULL          | idx_actor_last_name | 182     | NULL |  200 |   100.00 | Using where; Using index |+----+-------------+-------+------------+-------+---------------+---------------------+---------+------+------+----------+--------------------------+1 row in set, 1 warning (0.02 sec)

第一个

type

是

const

效率高于第二条语句

index

。

2. 尽量使用主键查询，而不是其他索引，因为主键查询不会触发回表查询

关于

回表

，欢迎查看MySQL优化必备之执行计划explain，索引基本知识，索引数据结构推演中提到的索引基本知识。

3. 使用前缀索引

有时候需要索引很长的字符串，这会让索引变的大且慢，通常情况下可以使用某个列开始的部分字符串，这样大大的节约索引空间，从而提高索引效率。

但这会降低索引的选择性，索引的选择性是指不重复的索引值和数据表记录总数的比值，范围从1/#T到1之间。

索引的选择性越高则查询效率越高，因为选择性更高的索引可以让MySQL在查找的时候过滤掉更多的行。

一般情况下某个列前缀的选择性也是足够高的，足以满足查询的性能，但是对应BLOB,TEXT,VARCHAR类型的列，必须要使用前缀索引，因为MySQL不允许索引这些列的完整长度，使用该方法的诀窍在于要选择足够长的前缀以保证较高的选择性，通过又不能太长。

我们来构造一些数据表和数据：

mysql> create table citydemo(city varchar(50) not null);Query OK, 0 rows affected (0.04 sec)mysql> insert into citydemo(city) select city from city;Query OK, 600 rows affected (0.03 sec)Records: 600  Duplicates: 0  Warnings: 0mysql> insert into citydemo(city) select city from citydemo;Query OK, 600 rows affected (0.03 sec)Records: 600  Duplicates: 0  Warnings: 0mysql> insert into citydemo(city) select city from citydemo;Query OK, 1200 rows affected (0.01 sec)Records: 1200  Duplicates: 0  Warnings: 0mysql> insert into citydemo(city) select city from citydemo;Query OK, 2400 rows affected (0.05 sec)Records: 2400  Duplicates: 0  Warnings: 0mysql> insert into citydemo(city) select city from citydemo;\\Query OK, 4800 rows affected (0.09 sec)Records: 4800  Duplicates: 0  Warnings: 0mysql> insert into citydemo(city) select city from citydemo;Query OK, 9600 rows affected (0.16 sec)Records: 9600  Duplicates: 0  Warnings: 0

如此，我们构造了一些重复数据。

查找最常见的城市列表：

mysql> select count(*) as cnt,city from citydemo group by city order by cnt desc limit 10;+-----+------------------+| cnt | city             |+-----+------------------+|  64 | London           ||  32 | Omiya            ||  32 | Pontianak        ||  32 | Antofagasta      ||  32 | Salala           ||  32 | Batna            ||  32 | Shubra al-Khayma ||  32 | Brescia          ||  32 | Sunnyvale        ||  32 | Clarksville      |+-----+------------------+10 rows in set (0.04 sec)

发现每个值都出现了32+次，我们来查找最频繁出现的城市前缀，先从3个前缀字母开始：

mysql> select count(*) as cnt,left(city,3) as pref from citydemo group by pref order by cnt desc limit 10;+-----+------+| cnt | pref |+-----+------+| 448 | San  || 192 | Cha  || 160 | Sal  || 160 | Tan  || 160 | Sou  || 160 | al-  || 128 | Hal  || 128 | Bat  || 128 | Man  || 128 | Sha  |+-----+------+

可以看到用

left(city,3)

截取前三个作为前缀查询的结果和之前整列查找差别比较大，继续增加截取的字符数查询，这次用

left(city, 5)

：

mysql> select count(*) as cnt,left(city,5) as pref from citydemo group by pref order by cnt desc limit 10;+-----+-------+| cnt | pref  |+-----+-------+| 128 | South ||  96 | Santa ||  64 | Chang ||  64 | Toulo ||  64 | Santi ||  64 | Xiang ||  64 | Valle ||  64 | Londo ||  64 | Saint ||  64 | San F |+-----+-------+

如你所见，差别变小了，以此法继续，最后确定

left(city, 7)

和最终的结果最接近：

mysql> select count(*) as cnt,left(city,7) as pref from citydemo group by pref order by cnt desc limit 10;+-----+---------+| cnt | pref    |+-----+---------+|  64 | Valle d ||  64 | Santiag ||  64 | London  ||  64 | San Fel ||  32 | Antofag ||  32 | Batna   ||  32 | Brescia ||  32 | Clarksv ||  32 | El Mont ||  32 | Greensb |+-----+---------+

也就是说，此时前缀的选择性接近于完整列的选择性。

前面说

索引的选择性是指不重复的索引值和数据表记录总数的比值

，那么计算完整列的选择性，还可以用如下方法：

select count(distinct left(city,3))/count(*) as sel3,count(distinct left(city,4))/count(*) as sel4,count(distinct left(city,5))/count(*) as sel5,count(distinct left(city,6))/count(*) as sel6,count(distinct left(city,7))/count(*) as sel7,count(distinct left(city,8))/count(*) as sel8from citydemo;

结果：

至此，我们就可以愉快的建立前缀索引了：

alter table citydemo add key(city(7));

用一下瞅瞅：

type

是

ref

级别的，效率还是很好的！

注意：前缀索引是一种能使索引更小更快的有效方法，但是也包含缺点：MySQL无法使用前缀索引做order by 和 group by。

4. 使用索引扫描来排序

MySQL有两种方式可以生成有序的结果：通过排序操作或者按索引顺序扫描，如果explain出来的type列的值为index,则说明MySQL使用了索引扫描来做排序。

扫描索引本身是很快的，因为只需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列，那么就不得不每扫描一条索引记录就得回表查询一次对应的行，这基本都是随机IO，因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢。

MySQL可以使用同一个索引即满足排序，又用于查找行，如果可能的话，设计索引时应该尽可能地同时满足这两种任务。

只有当索引的列顺序和order by子句的顺序完全一致，并且所有列的排序方式都一样时，MySQL才能够使用索引来对结果进行排序，如果查询需要关联多张表，则只有当order by子句引用的字段全部为第一张表时，才能使用索引做排序。order by子句和查找型查询的限制是一样的，需要满足索引的最左前缀的要求，否则，MySQL都需要执行顺序操作，而无法利用索引排序。

sakila

数据库中

rental

表在rental_date,inventory_id,customer_id上有名称为

rental_date

的组合索引：

eg.1

mysql> explain select rental_id,staff_id from rental where rental_date=\'2005-05-25\' order by inventory_id,customer_id\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: refpossible_keys: rental_datekey: rental_datekey_len: 5ref: constrows: 1filtered: 100.00Extra: Using index condition1 row in set, 1 warning (0.03 sec)

此处order by子句不满足索引的最左前缀的要求，也可以用于查询排序，这是因为查询的第一列
rental_date=\'2005-05-25\'
被指定为一个常数。

eg. 2

mysql> explain select rental_id,staff_id from rental where rental_date=\'2005-05-25\' order by inventory_id desc\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: refpossible_keys: rental_datekey: rental_datekey_len: 5ref: constrows: 1filtered: 100.00Extra: Using where1 row in set, 1 warning (0.03 sec)

该查询为索引的第一列提供了常量条件，而使用第二列进行排序，将两个列组合在一起，就形成了索引的最左前缀（顺序为rental_date,inventory_id）

eg.3

mysql> explain select rental_id,staff_id from rental where rental_date>\'2005-05-25\' order by rental_date,inventory_id\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: ALLpossible_keys: rental_datekey: NULLkey_len: NULLref: NULLrows: 16005filtered: 50.00Extra: Using where; Using filesort1 row in set, 1 warning (0.00 sec)

该查询第一列用的是范围查询，根据前面的铺垫，后面无论顺序如何，都不会按照索引进行排序了。从运行结果也能看到，该查询没有利用索引（
Using filesort
）。

eg. 4

mysql> explain select rental_id,staff_id from rental where rental_date=\'2005-05-25\' order by inventory_id desc,customer_id asc\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: refpossible_keys: rental_datekey: rental_datekey_len: 5ref: constrows: 1filtered: 100.00Extra: Using index condition; Using filesort1 row in set, 1 warning (0.00 sec)

该查询使用了两中不同的排序方向（先desc，后asc），但是索引列都是正序排序的，从结果看（
Using filesort
），也没有利用索引进行排序。

eg. 5

mysql> explain select rental_id,staff_id from rental where rental_date=\'2005-05-25\' order by inventory_id desc,customer_id desc\\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: refpossible_keys: rental_datekey: rental_datekey_len: 5ref: constrows: 1filtered: 100.00Extra: Using where1 row in set, 1 warning (0.00 sec)

这个就用到了索引排序。

结合eg. 4，为什么按照两个方向（先desc，后asc）进行排序不利用索引，而同一方向就用了呢？

答：建立索引的时候默认是按照升序存储的，在B+树上，从上往下查找，如果都是desc，反过来从下往上查找即可。但是你同时整了两个方向的查找，B+树上，在一个节点里面还怎么对它进行排序，怎么直接读取索引里面的值？不能了吧。

熬夜不易，且行且珍惜。