通过索引进行优化
索引基本知识
索引的优点
1、大大减少了服务器需要扫描的数据量
2、帮助服务器避免排序和临时表
3、将随机io变成顺序io
索引的用处
-
快速查找匹配WHERE子句的行
-
从consideration中消除行,如果可以在多个索引之间进行选择,mysql通常会使用找到最少行的索引
-
如果表具有多列索引,则优化器可以使用索引的任何最左前缀来查找行
-
当有表连接的时候,从其他表检索行数据
-
查找特定索引列的min或max值
-
如果排序或分组时在可用索引的最左前缀上完成的,则对表进行排序和分组
-
在某些情况下,可以优化查询以检索值而无需查询数据行
索引的分类
- 普通索引NORMAL:仅加速查询
- 唯一索引UNIQUE:加速查询 + 列值唯一(可以有null)
- 主键索引PRIMARY:加速查询 + 列值唯一(不可以有null)+ 表中只有一个
- 组合索引:多列值组成一个索引,专门用于组合搜索,其效率大于索引合并
- 全文索引FULLTEXT:对文本的内容进行分词,进行搜索
技术名词
- 回表
MySQL innodb的主键索引是簇集索引,也就是索引的叶子节点存的是整个单条记录的所有字段值
不是主键索引的就是非簇集索引,非簇集索引的叶子节点存的是主键字段的值。需要取其他列时,要根据主键再去查主键的B+树.
回表是什么意思?就是你执行一条sql语句,需要从两个b+索引中去取数据。 - 索引覆盖(or覆盖索引)
回表需要查询两次B+树,IO次数就比较多;
如果建立的普通索引/组合索引,我们查询的时候只需要查询该索引(或者主键),不需要查询其他列,就不需要回表了,这就是索引覆盖.
常见于组合索引 - 最左匹配
建立组合索引后,比如对三个列name,age和sex 建立了组合索引 index_name_age_sex
那么where name=? and age=? and sex=?时肯定可以用到索引
where name=? 或者 where where name=? and age=?时也可以用到索引 (使用多个where条件时,顺序无所谓,MySQL会帮我们优化调整成最左匹配的顺序)
如果达不到最左匹配,比如where age=?,则不会使用该组合索引
那怎么办?
可以把组合索引调整一下顺序,改成 index_age_name_sex;
或者给age单独建立一个索引
如果需要在为name和age单独创建索引中 二选一,那么我会选择age;因为age占用磁盘空间更少,减少磁盘IO. - 索引下推
(谓词下推?)
查询sql的过滤条件,比如where name=? and age=?
老版本的MySQL,server第一步会先根据name条件从存储引擎中取出数据,第二步在server层根据age筛选;
索引下推是说,在组合索引中,高版本MySQL会优化一下,会把第二步合并到第一步,在查询数据时就根据name和age筛选,减少了IO量. - 索引合并
低版本的MySQL没有这说法,一次查询只能用一个索引
高版本中,优化器会帮我们做组合,但是效率不一定高 - 索引页分裂 页合并
to be continued…
索引匹配方式
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);
全值匹配
全值匹配指的是和索引中的所有列进行匹配
explain select * from staffs where name = ‘July’ and age = ‘23’ and pos = ‘dev’;
±—±------------±-------±-----±--------------±--------±--------±------------------±-----±----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±------------±-------±-----±--------------±--------±--------±------------------±-----±----------------------+
| 1 | SIMPLE | staffs | ref | idx_nap | idx_nap | 140 | const,const,const | 1 | Using index condition |
±—±------------±-------±-----±--------------±--------±--------±------------------±-----±----------------------+
匹配最左前缀
只匹配前面的几列
explain select * from staffs where name = ‘July’ and age = ‘23’;
±—±------------±-------±-----±--------------±--------±--------±------------±-----±----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±------------±-------±-----±--------------±--------±--------±------------±-----±----------------------+
| 1 | SIMPLE | staffs | ref | idx_nap | idx_nap | 78 | const,const | 1 | Using index condition |
±—±------------±-------±-----±--------------±--------±--------±------------±-----±----------------------+
explain select * from staffs where age = ‘23’;
±—±------------±-------±-----±--------------±-----±--------±-----±-----±------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±------------±-------±-----±--------------±-----±--------±-----±-----±------------+
| 1 | SIMPLE | staffs | ALL | NULL | NULL | NULL | NULL | 1 | Using where |
±—±------------±-------±-----±--------------±-----±--------±-----±-----±------------+
匹配列前缀
可以匹配某一列的值的开头部分
explain select * from staffs where name like ‘J%’;
±—±------------±-------±------±--------------±--------±--------±-----±-----±----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±------------±-------±------±--------------±--------±--------±-----±-----±----------------------+
| 1 | SIMPLE | staffs | range | idx_nap | idx_nap | 74 | NULL | 1 | Using index condition |
±—±------------±-------±------±--------------±--------±--------±-----±-----±----------------------+
explain select * from staffs where name like ‘%y’;
±—±------------±-------±-----±--------------±-----±--------±-----±-----±------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±------------±-------±-----±--------------±-----±--------±-----±-----±------------+
| 1 | SIMPLE | staffs | ALL | NULL | NULL | NULL | NULL | 1 | Using where |
±—±------------±-------±-----±--------------±-----±--------±-----±-----±------------+
匹配范围值
可以查找某一个范围的数据
explain select * from staffs where name > ‘Mary’;
±—±------------±-------±------±--------------±--------±--------±-----±-----±----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±------------±-------±------±--------------±--------±--------±-----±-----±----------------------+
| 1 | SIMPLE | staffs | range | idx_nap | idx_nap | 74 | NULL | 1 | Using index condition |
±—±------------±-------±------±--------------±--------±--------±-----±-----±----------------------+
精确匹配某一列并范围匹配另外一列
可以查询第一列的全部和第二列的部分
explain select * from staffs where name = ‘July’ and age > 25;
±—±------------±-------±------±--------------±--------±--------±-----±-----±----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±------------±-------±------±--------------±--------±--------±-----±-----±----------------------+
| 1 | SIMPLE | staffs | range | idx_nap | idx_nap | 78 | NULL | 1 | Using index condition |
±—±------------±-------±------±--------------±--------±--------±-----±-----±----------------------+
只访问索引的查询
查询的时候只需要访问索引,不需要访问数据行,本质上就是覆盖索引
explain select name,age,pos from staffs where name = ‘July’ and age = 25 and pos = ‘dev’;
±—±------------±-------±-----±--------------±--------±--------±------------------±-----±-------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
±—±------------±-------±-----±--------------±--------±--------±------------------±-----±-------------------------+
| 1 | SIMPLE | staffs | ref | idx_nap | idx_nap | 140 | const,const,const | 1 | Using where; Using index |
±—±------------±-------±-----±--------------±--------±--------±------------------±-----±-------------------------+
哈希索引
基于哈希表的实现,只有精确匹配索引所有列的查询才有效
在mysql中,只有memory的存储引擎显式支持哈希索引
哈希索引自身只需存储对应的hash值,所以索引的结构十分紧凑,这让哈希索引查找的速度非常快
哈希索引的限制:
1、哈希索引只包含哈希值和行指针,而不存储字段值,索引不能使用索引中的值来避免读取行
2、哈希索引数据并不是按照索引值顺序存储的,所以无法进行排序
3、哈希索引不支持部分列匹配查找,哈希索引是使用索引列的全部内容来计算哈希值
4、哈希索引支持等值比较查询,也不支持任何范围查询
5、访问哈希索引的数据非常快,除非有很多哈希冲突,当出现哈希冲突的时候,存储引擎必须遍历链表中的所有行指针,逐行进行比较,直到找到所有符合条件的行
6、哈希冲突比较多的话,维护的代价也会很高
组合索引
当包含多个列作为索引,需要注意的是正确的顺序依赖于该索引的查询,同时需要考虑如何更好的满足排序和分组的需要
案例:
建立组合索引a,b,c,不同SQL语句使用索引情况
聚簇索引与非聚簇索引
非聚簇索引
数据文件跟索引文件分开存放(MyISAM)
聚簇索引
不是单独的索引类型,而是一种数据存储方式,指的是数据行跟相邻的键值紧凑的存储在一起
优点:
1、可以把相关数据保存在一起
2、数据访问更快,因为索引和数据保存在同一个树中
3、使用覆盖索引扫描的查询可以直接使用页节点中的主键值
缺点:
1、聚簇数据最大限度地提高了IO密集型应用的性能,如果数据全部在内存,那么聚簇索引就没有什么优势
2、插入速度严重依赖于插入顺序,按照主键的顺序插入是最快的方式(页分裂和页合并)
3、更新聚簇索引列的代价很高,因为会强制将每个被更新的行移动到新的位置
4、基于聚簇索引的表在插入新行,或者主键被更新导致需要移动行的时候,可能面临页分裂的问题
5、聚簇索引可能导致全表扫描变慢,尤其是行比较稀疏,或者由于页分裂导致数据存储不连续的时候
当使用B+树进行数据存储时,每个叶子节点可以插入几条记录是可以知道的(根据表的类型,每条记录是有大小限制的)
页分裂: 假如经过判断,需要在某个索引块中插入数据,如果这个索引块中没有空余位置了,就会页分裂,新增一个索引块,把原先的块中的数据分到两个索引块中(一人一半);页分裂会导致空间的浪费
页合并: 假如删除数据后,判断两个数据页可以合并成一个,就会把他俩合并
这个有点类似HBase中 region的分割
覆盖索引
基本介绍
1、如果一个索引包含所有需要查询的字段的值,我们称之为覆盖索引
2、不是所有类型的索引都可以称为覆盖索引,覆盖索引必须要存储索引列的值
3、不同的存储实现覆盖索引的方式不同,不是所有的引擎都支持覆盖索引,memory不支持覆盖索引
优势
1、索引条目通常远小于数据行大小,如果只需要读取索引,那么mysql就会极大的较少数据访问量
2、因为索引是按照列值顺序存储的,所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少的多
3、一些存储引擎如MYISAM在内存中只缓存索引,数据则依赖于操作系统来缓存,因此要访问数据需要一次系统调用,这可能会导致严重的性能问题
4、由于INNODB的聚簇索引,覆盖索引对INNODB表特别有用
案列
1、当发起一个被索引覆盖的查询时,在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)
2、在大多数存储引擎中,覆盖索引只能覆盖那些只访问索引中部分列的查询。不过,可以进一步的进行优化,可以使用innodb的二级索引来覆盖查询。
例如: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: 1
select_type: SIMPLE
table: actor
partitions: NULL
type: ref
possible_keys: idx_actor_last_name
key: idx_actor_last_name
key_len: 137
ref: const
rows: 2
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.00 sec)
优化小细节
当使用索引列进行查询的时候尽量不要使用表达式,把计算放到业务层而不是数据库层
select actor_id from actor where actor_id=4;
select actor_id from actor where actor_id+1=5;
(explain看看,system > const > ref > range > index > all)
尽量使用主键查询,而不是其他索引,因为主键查询不会触发回表查询
使用前缀索引
有时候需要索引很长的字符串,这会让索引变的大且慢,通常情况下可以使用某个列开始的部分字符串,这样大大的节约索引空间,从而提高索引效率,但这会降低索引的选择性,索引的选择性是指不重复的索引值和数据表记录总数的比值,范围从1/#T到1之间。索引的选择性越高则查询效率越高,因为选择性更高的索引可以让mysql在查找的时候过滤掉更多的行。
一般情况下某个列前缀的选择性也是足够高的,足以满足查询的性能,但是对应BLOB,TEXT,VARCHAR类型的列,必须要使用前缀索引,因为mysql不允许索引这些列的完整长度,使用该方法的诀窍在于要选择足够长的前缀以保证较高的选择性,通过又不能太长。
案例演示:
--创建数据表 (city表是官网样例sakila-db中的)
create table citydemo(city varchar(50) not null);
insert into citydemo(city) select city from city;
--重复执行5次下面的sql语句
insert into citydemo(city) select city from citydemo;
--更新城市表的名称
update citydemo set city=(select city from city order by rand() limit 1);
--查找最常见的城市列表,发现每个值都出现45-65次,
select count(*) as cnt,city from citydemo group by city order by cnt desc limit 10;
--查找最频繁出现的城市前缀,先从3个前缀字母开始,发现比原来出现的次数更多,可以分别截取多个字符查看城市出现的次数
select count(*) as cnt,left(city,3) as pref from citydemo group by pref order by cnt desc limit 10;
select count(*) as cnt,left(city,7) as pref from citydemo group by pref order by cnt desc limit 10;
--此时前缀的选择性接近于完整列的选择性
--还可以通过另外一种方式来计算完整列的选择性,可以看到当前缀长度到达7之后,再增加前缀长度,选择性提升的幅度已经很小了
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 sel8
from citydemo;
--计算完成之后可以创建前缀索引
alter table citydemo add key(city(7));
--注意:前缀索引是一种能使索引更小更快的有效方法,但是也包含缺点:mysql无法使用前缀索引做order by 和 group by。
cardinality(基数)
可以理解成: count(distinct column), 但不是准确的值,是个预估值.
OLAP中,当两张表做关联分析时,同时满足需求的场景下,优先选择cardinality小的列做join
引申: HyperLoglog
使用索引扫描来排序
mysql有两种方式可以生成有序的结果:通过排序操作或者按索引顺序扫描,如果explain出来的type列的值为index,则说明mysql使用了索引扫描来做排序
扫描索引本身是很快的,因为只需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列,那么就不得不每扫描一条索引记录就得回表查询一次对应的行,这基本都是随机IO,因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢
mysql可以使用同一个索引即满足排序,又用于查找行,如果可能的话,设计索引时应该尽可能地同时满足这两种任务。
只有当索引的列顺序和order by子句的顺序完全一致,并且所有列的排序方式都一样时,mysql才能够使用索引来对结果进行排序,如果查询需要关联多张表,则只有当orderby子句引用的字段全部为第一张表时,才能使用索引做排序。order by子句和查找型查询的限制是一样的,需要满足索引的最左前缀的要求,否则,mysql都需要执行顺序操作,而无法利用索引排序
--sakila数据库中rental表在rental_date,inventory_id,customer_id上有rental_date的索引
--使用rental_date索引为下面的查询做排序
explain select rental_id,staff_id from rental where rental_date='2005-05-25' order by inventory_id,customer_id\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: rental
partitions: NULL
type: ref
possible_keys: rental_date
key: rental_date
key_len: 5
ref: const
rows: 1
filtered: 100.00
Extra: Using index condition
1 row in set, 1 warning (0.00 sec)
--order by子句不满足索引的最左前缀的要求,也可以用于查询排序,这是因为所以你的第一列被指定为一个常数
--该查询为索引的第一列提供了常量条件,而使用第二列进行排序,将两个列组合在一起,就形成了索引的最左前缀
explain select rental_id,staff_id from rental where rental_date='2005-05-25' order by inventory_id desc\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: rental
partitions: NULL
type: ref
possible_keys: rental_date
key: rental_date
key_len: 5
ref: const
rows: 1
filtered: 100.00
Extra: Using where
1 row in set, 1 warning (0.00 sec)
--下面的查询不会利用索引
explain select rental_id,staff_id from rental where rental_date>'2005-05-25' order by rental_date,inventory_id\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: rental
partitions: NULL
type: ALL
possible_keys: rental_date
key: NULL
key_len: NULL
ref: NULL
rows: 16005
filtered: 50.00
Extra: Using where; Using filesort
--该查询使用了两中不同的排序方向,但是索引列都是正序排序的
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: 1
select_type: SIMPLE
table: rental
partitions: NULL
type: ALL
possible_keys: rental_date
key: NULL
key_len: NULL
ref: NULL
rows: 16005
filtered: 50.00
Extra: Using where; Using filesort
1 row in set, 1 warning (0.00 sec)
--该查询中引用了一个不再索引中的列
explain select rental_id,staff_id from rental where rental_date>'2005-05-25' order by inventory_id,staff_id\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: rental
partitions: NULL
type: ALL
possible_keys: rental_date
key: NULL
key_len: NULL
ref: NULL
rows: 16005
filtered: 50.00
Extra: Using where; Using filesort
1 row in set, 1 warning (0.00 sec)
union all,in,or都能够使用索引,但是推荐使用in
explain select * from actor where actor_id = 1 union all select * from actor where actor_id = 2;
explain select * from actor where actor_id in (1,2);
explain select * from actor where actor_id = 1 or actor_id =2;
能用union all 的地方尽量不适用union,因为union会有"去重"的操作
exist相当于是加了层for循环,可以用上外层循环的变量,做了个子查询关联,只有有值时才能查出结果;
exist不能取出子查询中的数据
在一些情况下,用exist会优于in,但是写起来比较麻烦
范围列可以用到索引
范围条件是:<、<=、>、>=、between
范围列可以用到索引,但是范围列后面的列无法用到索引,索引最多用于一个范围列
强制类型转换会全表扫描(varchar和int)
create table user(id int,name varchar(10),phone varchar(11));
alter table user add index idx_1(phone);
-- 不会触发索引
explain select * from user where phone=13800001234;
-- 会触发索引
explain select * from user where phone='13800001234';
更新十分频繁,数据区分度不高的字段上不宜建立索引
更新会变更B+树,更新频繁的字段建立索引会大大降低数据库性能
类似于性别这类区分不大的属性,建立索引是没有意义的,不能有效的过滤数据,
一般区分度在80%以上的时候就可以建立索引,区分度可以使用 count(distinct(列名))/count(*) 来计算
创建索引的列,尽量避免为null
null列可能会得到不符合预期的结果
条件判断时null 不等于 null,而是要用column is null 来判断 (where 或者 join时)
也会给存储和索引带来更多复杂度
当需要进行表连接的时候,最好不要超过三张表
(需要join的字段,数据类型最好一致,这样会在一个连接中进行join.hive是这样,MySQL? 待验证)
如果我们写的SQL中 A join B, 真正执行时不一定先读取A再读取B,MySQL可能会帮我们优化;
可以通过关键字指定不需要它帮忙优化
如果时A连接B,那么A就是驱动表,B一般称为匹配表/非驱动表
simple nested-loop join:
index nested-loop join:
block nested-loop join:
能使用limit的时候尽量使用limit
减少遍历和判断的行数
单表索引建议控制在5个以内
索引本身也是占用磁盘的,增/删/改时也是需要维护它的
单索引字段数不宜超过5个(组合索引)
最左匹配,很可能需要单独给后面的字段再开索引
索引监控
show status like ‘Handler_read%’;
参数解释:
Handler_read_first:读取索引第一个条目的次数
Handler_read_key:通过index获取数据的次数
Handler_read_last:读取索引最后一个条目的次数
Handler_read_next:通过索引读取下一条数据的次数
Handler_read_prev:通过索引读取上一条数据的次数
Handler_read_rnd:从固定位置读取数据的次数
Handler_read_rnd_next:从数据节点读取下一条数据的次数
简单来说, Handler_read_key和Handler_read_rnd_next越大越好,说明查询时使用索引的次数多
索引失效的情况
- like 以%开头,索引无效;当like前缀没有%,后缀有%时,索引有效。
- or语句前后没有同时使用索引。当or左右查询字段只有一个是索引,该索引失效,只有当or左右查询字段均为索引时,才会生效
- 组合索引,不是使用第一列索引,索引失效。(最左匹配)
- 数据类型出现隐式转化。如varchar不加单引号的话可能会自动转换为int型,使索引无效,产生全表扫描。
- 在索引列上使用 IS NULL 或 IS NOT NULL操作。索引是不索引空值的,所以这样的操作不能使用索引,可以用其他的办法处理,例如:数字类型,判断大于0,字符串类型设置一个默认值,判断是否等于默认值即可。
- 在索引字段上使用not,<>,!=。不等于操作符是永远不会用到索引的,因此对它的处理只会产生全表扫描。 优化方法: key<>0 改为 key>0 or key<0。
- 对索引字段进行计算操作、字段上使用函数。(索引为 emp(ename,empno,sal))
节点读取下一条数据的次数
简单来说, Handler_read_key和Handler_read_rnd_next越大越好,说明查询时使用索引的次数多
索引失效的情况
- like 以%开头,索引无效;当like前缀没有%,后缀有%时,索引有效。
- or语句前后没有同时使用索引。当or左右查询字段只有一个是索引,该索引失效,只有当or左右查询字段均为索引时,才会生效
- 组合索引,不是使用第一列索引,索引失效。(最左匹配)
- 数据类型出现隐式转化。如varchar不加单引号的话可能会自动转换为int型,使索引无效,产生全表扫描。
- 在索引列上使用 IS NULL 或 IS NOT NULL操作。索引是不索引空值的,所以这样的操作不能使用索引,可以用其他的办法处理,例如:数字类型,判断大于0,字符串类型设置一个默认值,判断是否等于默认值即可。
- 在索引字段上使用not,<>,!=。不等于操作符是永远不会用到索引的,因此对它的处理只会产生全表扫描。 优化方法: key<>0 改为 key>0 or key<0。
- 对索引字段进行计算操作、字段上使用函数。(索引为 emp(ename,empno,sal))
- 当全表扫描速度比索引速度快时,mysql会使用全表扫描,此时索引失效。