Explain分析-Mysql索引优化（三）

欢迎大家关注我的微信公众号：

传送门：Explain分析——索引优化实践

传送门：Explain分析-Mysql索引优化（二）

目录

分页查询优化?

Join关联查询优化

in和exsits优化?

count(*)查询优化?

分页查询优化?

示例表：

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='员工记录表';

?很多时候我们业务系统实现分页功能可能会用如下sql实现：

 mysql> select * from employees limit 10000,10;

>>常见的分页场景优化技巧：?

mysql> select * from employees limit 90000,5;

mysql> select * from employees where id > 90000 limit 5;

?查询的结果是一致的。我们再对比一下执行计划：

mysql> EXPLAIN select * from employees limit 90000,5;

mysql> EXPLAIN select * from employees where id > 90000 limit 5;

显然改写后的 SQL 走了索引，而且扫描的行数大大减少，执行效率更高。

• 主键自增且连续
• 结果是按照主键排序的

2、根据非主键字段排序的分页查询

再看一个根据非主键字段排序的分页查询，SQL 如下：

mysql> select * from employees ORDER BY name limit 90000,5;

mysql> EXPLAIN select * from employees ORDER BY name limit 90000,5;

mysql> select * from employees e inner join (select id from employees order by name limit 90000,5) ed on e.id = ed.id;

原 SQL 使用的是 filesort 排序，而优化后的 SQL 使用的是索引排序。?

Join关联查询优化

-- 示例表：
CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

create table t2 like t1;

-- 插入一些示例数据
-- 往t1表插入1万行记录
drop?procedure?if?exists?insert_t1;?
delimiter?;;
create?procedure?insert_t1()????????
begin
??declare?i?int;????????????????????
??set?i=1;??????????????????????????
??while(i<=10000)do?????????????????
????insert?into?t1(a,b)?values(i,i);??
????set?i=i+1;???????????????????????
??end?while;
end;;
delimiter?;
call?insert_t1();

-- 往t2表插入100行记录
drop?procedure?if?exists?insert_t2;?
delimiter?;;
create?procedure?insert_t2()????????
begin
??declare?i?int;????????????????????
??set?i=1;??????????????????????????
??while(i<=100)do?????????????????
????insert?into?t2(a,b)?values(i,i);??
????set?i=i+1;???????????????????????
??end?while;
end;;
delimiter?;
call?insert_t2();

• Nested-Loop Join 算法
• Block Nested-Loop Join 算法

1、 嵌套循环连接 Nested-Loop Join(NLJ) 算法

mysql> EXPLAIN select * from t1 inner join t2 on t1.a= t2.a;

• 驱动表是 t2，被驱动表是 t1。先执行的就是驱动表(执行计划结果的id如果一样则按从上到下顺序执行sql)；优化器一般会优先选择小表做驱动表。所以使用 inner join 时，排在前面的表并不一定就是驱动表。
• 当使用left join时，左表是驱动表，右表是被驱动表，当使用right join时，右表时驱动表，左表是被驱动表，当使用join时，mysql会选择数据量比较小的表作为驱动表，大表作为被驱动表。
• 使用了 NLJ算法。一般 join 语句中，如果执行计划 Extra 中未出现 Using join buffer 则表示使用的 join 算法是 NLJ。

1. 从表 t2 中读取一行数据（如果t2表有查询过滤条件的，会从过滤结果里取出一行数据）；
2. 从第 1 步的数据中，取出关联字段 a，到表 t1 中查找；
3. 取出表 t1 中满足条件的行，跟 t2 中获取到的结果合并，作为结果返回给客户端；
4. 重复上面 3 步。

2、 基于块的嵌套循环连接 Block Nested-Loop Join(BNL)算法?

mysql>EXPLAIN select * from t1 inner join t2 on t1.b= t2.b;

?Extra 中 的Using join buffer (Block Nested Loop)说明该关联查询使用的是 BNL 算法。

1. 把 t2 的所有数据放入到 join_buffer 中
2. 把表 t1 中每一行取出来，跟 join_buffer 中的数据做对比
3. 返回满足 join 条件的数据

被驱动表的关联字段没索引为什么要选择使用 BNL 算法而不使用 Nested-Loop Join 呢？

• 关联字段加索引，让mysql做join操作时尽量选择NLJ算法。驱动表因为需要全部查询出来，所以过滤的条件也尽量要走索引，避免全表扫描，总之，能走索引的过滤条件尽量都走索引
• 小表驱动大表，写多表连接sql时如果明确知道哪张表是小表可以用straight_join写法固定连接驱动方式，省去 mysql优化器自己判断的时间

• straight_join只适用于inner join，并不适用于left join，right join。（因为left join，right join已经代表指定了表的执行顺序）
• 尽可能让优化器去判断，因为大部分情况下mysql优化器是比人要聪明的。使用straight_join一定要慎重，因为部分情况下人为指定的执行顺序并不一定会比优化引擎要靠谱。

in和exsits优化?

?原则：小表驱动大表，即小的数据集驱动大的数据集

select * from A where id in (select id from B)  
#等价于：
　　for(select id from B){
      select * from A where A.id = B.id
    }

select * from A where exists (select 1 from B where B.id = A.id)
#等价于:
    for(select * from A){
      select * from B where B.id = A.id
    }
    
#A表与B表的ID字段应建立索引

count(*)查询优化?

-- 临时关闭mysql查询缓存，为了查看sql多次执行的真实时间
mysql> set global query_cache_size=0;
mysql> set global query_cache_type=0;

mysql> EXPLAIN select count(1) from employees;
mysql> EXPLAIN select count(id) from employees;
mysql> EXPLAIN select count(name) from employees;
mysql> EXPLAIN select count(*) from employees;

?注意：以上4条sql只有根据某个字段count不会统计字段为null值的数据行

四个sql的执行计划一样，说明这四个sql执行效率应该差不多

• 字段有索引：count(*)≈count(1)>count(字段)>count(主键 id) //字段有索引，count(字段)统计走二级索引，二级索引存储数据比主键索引少，所以count(字段)>count(主键 id)
• 字段无索引：count(*)≈count(1)>count(主键 id)>count(字段) //字段没有索引count(字段)统计走不了索引，count(主键 id)还可以走主键索引，所以count(主键 id)>count(字段)
• count(1)跟count(字段)执行过程类似，不过count(1)不需要取出字段统计，就用常量1做统计，count(字段)还需要取出字段，所以理论上count(1)比count(字段)会快一点。
• count(*) 是例外，mysql并不会把全部字段取出来，而是专门做了优化，不取值，按行累加，效率很高，所以不需要用count(列名)或count(常量)来替代 count(*)。
• 为什么对于count(id)，mysql最终选择辅助索引而不是主键聚集索引？因为二级索引相对主键索引存储数据更少，检索性能应该更高，mysql内部做了点优化(应该是在5.7版本才优化)。

?

?