03|索引优化

数据准备

创建联合索引 KEY idx_name_age_position (name,age,position) USING BTREE

CREATE TABLE `employees` (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名',`age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',`position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位',`hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间',PRIMARY KEY (`id`),KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='员工记录表';

INSERT INTO employees(name,age,position,hire_time) VALUES('LiLei',22,'manager',NOW());
INSERT INTO employees(name,age,position,hire_time) VALUES('HanMeimei', 23,'dev',NOW());
INSERT INTO employees(name,age,position,hire_time) VALUES('Lucy',23,'dev',NOW());
Drop procedure if exists insert_emp; 
delimiter ;;
create procedure insert_emp()        
begindeclare i int;                    set i=1;                          while(i<=100000)do                 insert into employees(name,age,position) values(CONCAT('zps',i),i,'dev');  set i=i+1;                       end while;
end;;
delimiter ;
call insert_emp();

运行以sql代码，生成数据下所示
在这里插入图片描述

1、联合索引第一个字段用范围不会走索引

EXPLAIN SELECT * FROM employees WHERE name > 'LiLei' AND age = 22 AND position ='manager';

通过possible_keys 我们知道这条语句可以走索引，但是没走

结论：联合索引第一个字段就用范围查找不会走索引，mysql内部可能觉得第一个字段就用范围，结果集应该很大，回表的效率不高，还不如全表扫描

2、强制走索引

EXPLAIN SELECT * FROM employees force index(idx_name_age_position) WHERE name > 'LiLei' AND age = 22 AND position ='manager';

发现查询结果相同，需要关闭查询缓存
– 关闭查询缓存
set global query_cache_size=0;
set global query_cache_type=0;
– 执行时间0.333s
SELECT * FROM employees WHERE name > ‘LiLei’;
– 执行时间0.444s
SELECT * FROM employees force index(idx_name_age_position) WHERE name > ‘LiLei’;

运行结果对比
● 扫描行数 50001 < 1000002
● 执行时间 0.249s < 1.288s

结论：虽然使用了强制走索引让联合索引第一个字段范围查找也走索引，扫描的行rows看上去也少了点，但是最终查找效率不一定比全表扫描高，因为回表效率不高

3、覆盖索引优化

EXPLAIN SELECT name,age,position FROM employees WHERE name > 'LiLei' AND age = 22 AND position ='manag
er';

使用覆盖索引mysql只会在辅助索引树上去扫描，这里就走了索引，我们可以看到 key_len = 74

4、in和or在表数据量比较大的情况会走索引，在表记录不多的情况下会选择全表扫描

#10W记录
#in 
EXPLAIN SELECT * FROM employees WHERE name in ('LiLei','HanMeimei','Lucy') AND age = 22 AND position ='manager';#or 
EXPLAIN SELECT * FROM employees WHERE (name = 'LiLei' or name = 'HanMeimei') AND age = 22 AND position
='manager';

#3条记录
#in
EXPLAIN SELECT * FROM employees_copy WHERE name in ('LiLei','HanMeimei','Lucy') AND age = 22 AND posit
ion ='manager';#or
EXPLAIN SELECT * FROM employees_copy WHERE (name = 'LiLei' or name = 'HanMeimei') AND age = 22 AND position ='manager';

结论：实验发现在数据量比较大的情况下in，or都会走索引，但是数据量小的情况下不会走索引(数据量小还需要回表，直接全表扫可能更快) (5.7)
8.0版本在数据量小的情况下也会走索引

5、like KK% 一般情况都会走索引

#数据量10W：EXPLAIN SELECT * FROM employees WHERE name like 'LiLei%' AND age = 22 AND position ='manager';#数据量3:EXPLAIN SELECT * FROM employees_copy WHERE name like 'LiLei%' AND age = 22 AND position ='manager';

为什么like%会走索引？

like KK%用到了索引下推（Index Condition Pushdown，ICP）优化
对于辅助的联合索引(name,age,position)，正常情况按照最左前缀原则，SELECT * FROM employees WHERE name like ‘LiLei%’ AND age = 22 AND position =‘manager’ 这种情况只会走name字段索引，因为根据name字段过滤完，得到的索引行里的age和position是无序的，无法很好的利用索引。

MySQL5.6之前的版本只看一个字段

查询只能在联合索引里匹配到名字是 ‘LiLei’ 开头的索引，然后拿这些索引对应的主键逐个回表，到主键索引上找出相应的记录，再比对age和position这两个字段的值是否符合。
在这里插入图片描述

MySQL 5.6之后的版本多推几个字段

引入了索引下推优化，可以在索引遍历过程中，对索引中包含的所有字段先做判断，过滤掉不符合条件的记录之后再回表，可以有效的减少回表次数。使用了索引下推优化后，上面那个查询在联合索引里匹配到名字是 ‘LiLei’ 开头的索引之后，同时还会在索引里过滤age和position这两个字段，拿着过滤完剩下的索引对应的主键id再回表查整行数据。
在这里插入图片描述