最左前缀匹配原则

Order by 与Group by 优化

案例

优化总结

Using filesort文件排序原理详解

索引设计原则

分页查询优化

Join管理查询优化

嵌套循环NJL算法

基于块的嵌套循环连接BNL算法

对于关联sql的优化

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='员工记录表';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)doinsert into employees(name,age,position) values(CONCAT('zhuge',i),i,'dev');set i=i+1;end while;end;;delimiter ;call insert_emp();

最左前缀匹配原则

上文介绍了Mysql的联合索引，在MySQL建立联合索引时会遵守最左前缀匹配原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。

Order by 与Group by 优化

案例

案例一：

 EXPLAIN SELECT * FROM  employees WHERE name = 'LiLei' and position = 'dev' ORDER BY age;

分析:根据最左前缀规则，中间字段不能断，因此查询用到了name索引，从key_len=74可以看出。age字段对应索引用在了排序过程，因为Extra字段中没有 using filesort。联想到B+中联合索引的结构，查询可以跟进name确定扫描范围，而age作为联合索引第二个字段可以作为排序依据，即name在相等的情况下则age一定有序。

案例二：

 EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' ORDER BY position;

分析: 从explain的执行结果来看:key_len=74，查询使用了name索引，由于用了position进行排序，跳过了 age，出现了Using filesort。

案例三：

 EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' ORDER BY age, position;

分析:查找只用到索引name，age和position用于排序，无Using filesort。

案例四：

  EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' ORDER BY  position, age;

分析：和案例三中explain的执行结果一样，但是出现了Using filesort，因为索引的创建顺序为 name,age,position，但是排序的时候age和position颠倒位置了。

案例五：

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' AND age = 18 ORDER BY  position, age;

分析：与Case 4对比，在Extra中并未出现Using filesort，因为age为常量，在排序中被优化，所以索引未颠倒，不会出现Using filesort。

案例六

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' ORDER BY age ASC,position DESC;

分析：虽然排序的字段列与索引顺序一样，且order by默认升序，这里position desc变成了降序，导致与索引的排序方式不同，从而产生Using filesort。Mysql8以上版本有降序索引可以支持该种查询方式。

案例七

EXPLAIN SELECT * FROM employees WHERE name in ('LiLei', 'zhuge') ORDER BY age ,position

分析：对于排序来说，多个相等条件也是范围查询。这里根据name排序检索处理来的结果拼接到一起，从age开始，结果集是无序的。所以使用了fileSort

案例八

EXPLAIN SELECT * FROM employees WHERE NAME > 'a' ORDER BY name;

分析：根据name查询确定结果后，发现数据量太大，且发现查询条件是select * 需要回表操作，不如采用全表扫描节省资源，故不使用索引排序。

可以用覆盖索引优化后

EXPLAIN SELECT name, age,position  FROM employees WHERE NAME > 'a' ORDER BY name;

优化总结

Using filesort文件排序原理详解

单路排序:是一次性取出满足条件行的所有字段，然后在sort buffer中进行排序;用trace工具可以看到sort_mode信息里显示< sort_key, additional_fields >或者< sort_key, packed_additional_fields >
双路排序(又叫回表排序模式):是首先根据相应的条件取出相应的排序字段和可以直接定位行数据的行 ID，然后在 sort buffer 中进行排序，排序完后需要再次取回其它需要的字段;用trace工具可以看到sort_mode信息里显示< sort_key, rowid >

MySQL 通过比较系统变量 max_length_for_sort_data(默认1024字节) 的大小和需要查询的字段总大小来判断使用哪种排序模式。

如果字段的总长度小于max_length_for_sort_data ，那么使用单路排序模式;
如果字段的总长度大于max_length_for_sort_data ，那么使用双路排序模∙式。

索引设计原则

代码先行，索引后上

一般应该等到主体业务功能开发完毕，把涉及到该表相关sql都要拿出来分析之后再建立索引。

联合索引尽量覆盖条件

比如可以设计一个或者两三个联合索引(尽量少建单值索引)，让每一个联合索引都尽量去包含sql语句里的 where、order by、group by的字段，还要确保这些联合索引的字段顺序尽量满足sql查询的最左前缀原则。

不要在小基数字段上建立索引

索引基数是指这个字段在表里总共有多少个不同的值，比如一张表总共100万行记录，其中有个性别字段，其值不是男就是女，那么该字段的基数就是2。如果对这种小基数字段建立索引的话，还不如全表扫描了，因为你的索引树里就包含男和女两种值，根本没法进行快速的二分查找，那用索引就没有太大的意义了。一般建立索引，尽量使用那些基数比较大的字段，就是值比较多的字段，那么才能发挥出B+树快速二分查找的优势来。

长字符串我们可以采用前缀索引

尽量对字段类型较小的列设计索引，比如说什么tinyint之类的，因为字段类型较小的话，占用磁盘空间也会比较小，此时在搜索的时候性能也会比较好一点。当然，这个所谓的字段类型小一点的列，也不是绝对的，很多时候就是要针对varchar(255)这种字段建立索引，哪怕多占用一些磁盘空间也是有必要的。对于这种varchar(255)的大字段可能会比较占用磁盘空间，可以稍微优化下，比如针对这个字段的前20个字符建立索引，就是说，对这个字段里的每个值的前20个字符放在索引树里，类似于 KEY index(name(20),age,position)。此时你在where条件里搜索的时候，如果是根据name字段来搜索，那么此时就会先到索引树里根据name 字段的前20个字符去搜索，定位到之后前20个字符的前缀匹配的部分数据之后，再回到聚簇索引提取出来完整的name字段值进行比对。但是假如你要是order by name，那么此时你的name因为在索引树里仅仅包含了前20个字符，所以这个排序是没法用上索引的， group by也是同理。

where与order by冲突时优先where

在where和order by出现索引设计冲突时，到底是针对where去设计索引，还是针对order by设计索引?到底是让where去用上索引，还是让order by用上索引?

一般这种时候往往都是让where条件去使用索引来快速筛选出来一部分指定的数据，接着再进行排序。因为大多数情况基于索引进行where筛选往往可以最快速度筛选出你要的少部分数据，然后做排序的成本可能会小很多。

分页查询优化

优化前分页sql

select * from employees limit 10000,10;

看似只查询了 10 条记录，实际这条 SQL 是先读取 10010 条记录，然后抛弃前 10000 条记录，然后读到后面 10 条想要的数据。因此要查询一张大表比较靠后的数据，执行效率是非常低的。

主键是自增且连续的

优化后sql

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

但是，这条改写的SQL 在很多场景并不实用，因为表中可能某些记录被删后，主键空缺，导致结果不一致。

根据非主键字段

优化前分页sql

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

发现并没有使用 name 字段的索引(key 字段对应的值为 null)，具体原因上节课讲过:扫描整个索引并查找到没索引的行(可能要遍历多个索引树)的成本比扫描全表的成本更高，所以优化器放弃使用索引。

EXPLAIN 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()
begindeclare i int;set i=1;while(i<=10000)doinsert 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()
begindeclare i int;set i=1;while(i<=100)doinsert into t2(a,b) values(i,i);set i=i+1;end while;
end;;
delimiter ;
call insert_t2();

嵌套循环NJL算法

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。

上面sql的大致流程如下:

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

整个过程会读取 t2 表的所有数据(扫描100行)，然后遍历这每行数据中字段 a 的值，根据 t2 表中 a 的值索引扫描 t1 表中的对应行(扫描100次 t1 表的索引，1次扫描可以认为最终只扫描 t1 表一行完整数据，也就是总共 t1 表也扫描了100 行)。因此整个过程扫描了 200 行。如果被驱动表的关联字段没索引，使用NLJ算法性能会比较低(下面有详细解释)，mysql会选择Block Nested-Loop Join 算法。

基于块的嵌套循环连接BNL算法

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

上面sql的大致流程如下:

把 t2 的所有数据放入到 join_buffer 中
把表 t1 中每一行取出来，跟 join_buffer 中的数据做对比(这里的join_buffer理解为已经从磁盘一次性加载到join_buffer，其他数据与join_buffer对比只是计算，无需再进行磁盘扫描)
返回满足 join 条件的数据

整个过程对表 t1 和 t2 都做了一次全表扫描，因此扫描的总行数为10000(表 t1 的数据总量) + 100(表 t2 的数据总量) = 10100。并且 join_buffer里的数据是无序的，因此对表 t1 中的每一行，都要做 100 次判断，所以内存中的判断次数是 100 * 10000= 100 万次。
这个例子里表 t2 才 100 行，要是表 t2 是一个大表，join_buffer 放不下会怎么样join_buffer 的大小是由参数 join_buffer_size 设定的，默认值是 256k。如果放不下表 t2 的所有数据话，策略很简单，就是分段放。
比如 t2 表有1000行记录， join_buffer 一次只能放800行数据，那么执行过程就是先往 join_buffer 里放800行记录，然后从 t1 表里取数据跟 join_buffer 中数据对比得到部分结果，然后清空 join_buffer ，再放入 t2 表剩余200行记录，再次从 t1 表里取数据跟 join_buffer 中数据对比。所以就多扫了一次 t1 表。

被驱动表的关联字段没索引为什么要选择使用 BNL 算法而不使用 Nested-Loop Join 呢?
如果上面第二条sql使用 Nested-Loop Join，那么扫描行数为 100 * 10000 = 100万次，这个是磁盘扫描。很显然，用BNL磁盘扫描次数少很多，相比于磁盘扫描，BNL的内存计算会快得多。因此MySQL对于被驱动表的关联字段没索引的关联查询，一般都会使用 BNL 算法。如果有索引一般选择 NLJ 算法，有索引的情况下 NLJ 算法比 BNL算法性能更高

对于关联sql的优化

关联字段加索引，让mysql做join操作时尽量选择NLJ算法
小表驱动大表，写多表连接sql时如果明确知道哪张表是小表可以用straight_join写法固定连接驱动方式，省去mysql优化器自己判断的时间

in和exsits优化

原则:小表驱动大表，即小的数据集驱动大的数据集
in:当B表的数据集小于A表的数据集时，in优于exists

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

exists:当A表的数据集小于B表的数据集时，exists优于in 将主查询A的数据，放到子查询B中做条件验证，根据验证结果(true或false)来决定主查询的数据是否保留

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

EXISTS (subquery)只返回TRUE或FALSE,因此子查询中的SELECT * 也可以用SELECT 1替换,官方说法是实际执行时会忽略SELECT清单,因此没有区别
EXISTS子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比
EXISTS子查询往往也可以用JOIN来代替，何种最优需要具体问题具体分析

count查询优化

性能总结

字段有索引: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(*)。

常见优化方法

查询mysql自己维护的总行数
将总数维护到Redis里
增加数据库计数表

MySQL高级之SQL优化相关推荐

学习笔记之-MySql高级之sql优化
一 Mysql简介概述 MySQL是一个关系型数据库管理系统,由瑞典MySQL AB公司开发,目前属于Oracle公司. M/SQL是一种关联数据库管理系统,将数据保存在不同的表中,而不是将所有数据 ...
MySQL高级（SQL优化）
MySQL高级一.字符集 1.1.4个级别的字符集 1.2.字符集小结 1.3.字符集与比较规则 1.4.请求到响应过程中字符集的变化二.SQL大小写规范 2.1.Windows和Linux平台区 ...
MySQL进阶之SQL优化
1.使用 show status like 'Com%';可以查到各种语句执行的次数. Com_select:执行select操作的次数. Com_insert:执行insert的次数 Com_upd ...
MySQL数据库与SQL优化
一.MySQL 数据库与 SQL 优化 1.结构图二.MySQL 数据库引擎简介 1.ISAM(IndexedSequentialAccessMethod) ISAM 是一个定义明确且历经时 ...
Mysql数据库高级、sql优化
https://note.youdao.com/ynoteshare/index.html?id=53cd90b2a1d930e1f5c7558a3f595696&type=notebook& ...
MySQL高级 —— 查询性能优化
引言承接<MySQL高级 -- 高性能索引>,本篇博客将围绕<高性能MySQL(第三版)>第六章内容进行总结和概括. 与索引的部分一样,SQL优化也是广大程序员深入MySQL ...
MYSQL高级篇-----索引优化分析
索引优化分析下面是目录可跳转对应页面学习: 2. 索引优化分析 2.1 原因 SQL执行顺序 2.2 常见通用的join查询 2.3 索引 2.3.1 索引分类(重点) 2.3.2 索引结构 2.3 ...
MySQL高级及索引优化
这里写目录标题 MySQL高级 MySQL基础存储引擎 join(关联查询) join七种理论索引什么是索引索引分类索引数据结构建立索引情况索引分析 explain命令分析索引失效查 ...
Mysql索引，SQL优化
注:此文部分内容来自b站黑马程序员mysql高级课程 1. 索引 1.1 索引概述 MySQL官方对索引的定义为:索引(index)是帮助MySQL高效获取数据的数据结构(有序).在数据之外,数据库系 ...

MySQL高级之SQL优化

最左前缀匹配原则

Order by 与Group by 优化

案例

优化总结

Using filesort文件排序原理详解

索引设计原则

分页查询优化

Join管理查询优化

嵌套循环NJL算法

基于块的嵌套循环连接BNL算法

对于关联sql的优化

in和exsits优化

count查询优化

性能总结

常见优化方法

MySQL高级之SQL优化相关推荐

最新文章

热门文章