【mysql专辑】（2）mysql explain详解与索引最佳实践

学习索引优化，最重要是要理解mysql存储架构是b+树，可以看下之前的文章
深入理解Mysql索引底层数据结构与算法

示例表，下面的分析都是基于这个示例表来讲解

sql 复制代码

DROP TABLE IF EXISTS `actor`; 
CREATE TABLE `actor` (
  `id` int(11) NOT NULL,
  `name` varchar(45) DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `actor` (`id`, `name`, `update_time`) VALUES (1,'a','2017-12-22 15:27:18'), (2,'b','2017-12-22 15:27:18'), (3,'c','2017-12-22 15:27:18');

DROP TABLE IF EXISTS `film`;
CREATE TABLE `film` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `film` (`id`, `name`) VALUES (3,'film0'),(1,'film1'),(2,'film2');

DROP TABLE IF EXISTS `film_actor`;
CREATE TABLE `film_actor` (
  `id` int(11) NOT NULL,
  `film_id` int(11) NOT NULL,
  `actor_id` int(11) NOT NULL,
  `remark` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_film_actor_id` (`film_id`,`actor_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `film_actor` (`id`, `film_id`, `actor_id`) VALUES (1,1,1),(2,1,2),(3,2,1);

explain是用来分析sql语句性能的工具

看下这个简单的例子，大概理解一下每列是什么意思

1、id

这个是序列号，id大执行优先级高，id相同就从上到下执行，id为null最后执行

2、select type【这些看看就好了】

1）simple：简单查询。查询不包含子查询和union

2）primary：复杂查询中最外层的 select

3）subquery：包含在 select 中的子查询（不在 from 子句中）

4）derived：包含在 from 子句中的子查询。MySQL会将结果存放在一个临时表中，也称为派生表（derived的英文含义）

5）union：在 union 中的第二个和随后的 select

3. table列【这些看看就好了】

这一列表示 explain 的一行正在访问哪个表。

当 from 子句中有子查询时，table列是格式，表示当前查询依赖 id=N 的查询，于是先执行 id=N 的查询。

当有 union 时，UNION RESULT 的 table 列的值为<union1,2>，1和2表示参与 union 的 select 行id。

4. type列【这个重点关注下，面试有问过，会问有什么类型，什么意思】

这一列表示关联类型或访问类型，即MySQL决定如何查找表中的行，查找数据行记录的大概范围。

依次从最优到最差分别为：NULL > system > const > eq_ref > ref > range > index > all

一般来说，得保证查询达到range级别，最好达到ref

null

如果type为null，说明他能够在优化阶段分解查询语句，在执行阶段用不着访问表或者索引

const和system

可以理解他就是一个常量，比如你用主键或者唯一索引查询的时候，只可能有一条匹配的记录。

system是const的特例

看这个啊，2先执行，走的是主键索引，所以Type是const，然后他拿出来的记录再select，表里只有一条元组匹配时为system

还有个指令这里说下，show warnings可以得到优化后的查询语句，从而看出优化器优化了什么

那我们这里用这个看下

这里可以看到，select的就是个常量

eq_ref

看例子吧

也就是主键或者唯一索引的所有部分被连接使用，最多只会返回一条符合条件的记录，简单select是不会出现这种type

ref

相比于eq_ref 不用唯一索引，而是用普通索引或者唯一索引的部分前缀，索引要和某个值比较，可能会找到多个符合条件的行

简单 select 查询，name是普通索引（非唯一索引）

2.关联表查询，idx_film_actor_id是film_id和actor_id的联合索引，这里使用到了film_actor的左边前缀film_id部分。

range

范围扫描通常出现在in，between，< ,>, >=等操作中，使用一个索引来检索给定范围的行

index

扫描全索引就能拿到结果，一般是扫描某个二级索引，这种扫描不会从索引树根节点开始快速查找，而是直接对二级索引的叶子节点遍历和扫描，速度还是比较慢的，这种查询一般为使用覆盖索引，二级索引一般比较小，所以这种通常比ALL快一些。

这个含义是全索引是扫描，跟下面我要提到的all（全表扫描）是亲兄弟，但是效率比all高，为啥呢？我用这个图来解释

type为all，扫描的是聚簇索引，也叫主键索引，这个不懂的，可以看我文章最前面的那个文章链接。

也就是扫描整张表的物理数据，表里有多少行数据，就扫多少行，磁盘 IO 开销最大，效率最低；

那么type为index，扫描的是二级索引，也叫普通索引、联合索引，也就是扫描索引树本身，不扫描物理表数据，效率比 all 高

那为啥index比all快呢？

看图显而易见啊。

因为 MySQL 的二级索引体积远小于聚簇索引：二级索引只存「索引字段 + 主键值」，聚簇索引存「整行的所有字段数据」，扫描更小的索引树，磁盘 IO 更少，速度自然更快。

优化type:index的核心原则：为 SQL 增加有效筛选条件，让「全索引扫描」变成「索引精准匹配 / 范围匹配」，消灭全量扫描行为

所有 MySQL 查询优化核心原则：避免全量扫描（all/index），让 SQL 能命中索引做精准 / 范围检索

ALL

即全表扫描，扫描你的聚簇索引的所有叶子节点。通常情况下这需要增加索引来进行优化了。

5.possible key

这个是mysql认为可能用到哪个索引

有可能possible key是有值的，但是key没值，说明mysql觉得你这个索引对这个查询帮助不大，不如直接全表扫描，比如你数据量很少，我都懒得走索引，因为走完普通索引还得去回表查

如果possible key是null，你看下where，看要不要加个适当的索引来提升查询性能，然后再用explain看看

6.key

这个列是mysql实际选择哪个索引来优化对该表的访问

如果没有使用索引，则该列是 NULL。如果想强制mysql使用或忽视possible_keys列中的索引，在查询中使用 force index、ignore index。

7. key_len列

这一列显示了mysql在索引里使用的字节数，通过这个值可以算出具体使用了索引中的哪些列。

举例来说，film_actor的联合索引 idx_film_actor_id 由 film_id 和 actor_id 两个int列组成，并且每个int是4字节。通过结果中的key_len=4可推断出查询使用了第一个列：film_id列来执行索引查找。

key_len计算规则如下：

 字符串，char(n)和varchar(n)，5.0.3以后版本中，n均代表字符数，而不是字节数，如果是utf-8，一个数字或字母占1个字节，一个汉字占3个字节

 char(n)：如果存汉字长度就是 3n 字节

 varchar(n)：如果存汉字则长度是 3n + 2 字节，加的2字节用来存储字符串长度，因为varchar是变长字符串

 数值类型

 tinyint：1字节

 smallint：2字节

 int：4字节

 bigint：8字节

 时间类型

 date：3字节

 timestamp：4字节

 datetime：8字节

 如果字段允许为 NULL，需要1字节记录是否为 NULL

索引最大长度是768字节，当字符串过长时，mysql会做一个类似左前缀索引的处理，将前半部分的字符提取出来做索引。

总结，就是可以看长度来判断用到了联合索引中的那个

8. ref列

这一列显示了在key列记录的索引中，表查找值所用到的列或常量，常见的有：const（常量），字段名（例：film.id）

9. rows列

这一列是mysql估计要读取并检测的行数，注意这个不是结果集里的行数。

10. Extra列

这一列展示的是额外信息。常见的重要值如下：

1）using index 使用覆盖索引

看上图

key中有使用索引，如果select后面的字段都可以从这个索引树拿到，这种情况一般可以说用到了覆盖索引，extra里一般都有using index；

索引覆盖一般针对的是辅助索引，他能直接在辅助索引这棵树拿到结果，不用通过辅助索引再去主键索引树找其他字段

2）using where
使用 where 语句来处理结果，并且查询的列未被索引覆盖

3）using index condition

索引条件下推：联合索引前导列做范围查询时，MySQL 先通过索引过滤掉无效数据，再回表查全量字段，减少回表的行数，提升查询效率

查询的列不完全被索引覆盖，where条件中是一个前导列的范围

就是用联合索引最前面的字段做范围查询（比如联合索引(a,b)里用a>1）

这个时候肯定是要回表查的了

3个关键区分（彻底分清，不混淆）

✅ Using index（覆盖索引）：查的字段都在索引里，不用回表，性能更好；

✅ Using index condition（索引条件下推）：查的字段不全在索引里，需要回表，但先索引过滤再回表；

✅ 无这两个标识：直接全表扫描后过滤，无任何索引优化，性能最差。

终极极简版（3 句，全部一句话，背完通关）

索引条件下推 = 先索引过滤，再回表查询；

触发条件 = 联合索引前导列范围查询 + 非覆盖索引；

性能排序：Using index > Using index condition > 无标识。

4）using temporary

意思是mysql要建个临时表来处理查询，这种情况一般是要优化的，首先想到是用索引来优化

5）using filesort

使用外部排序而不是索引排序，数据较小是在内存排，否则要借助磁盘来排

6）Select tables optimized away：使用某些聚合函数（比如 max、min）来访问存在索引的某个字段是

索引最佳实践

sql 复制代码

示例表：
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=4 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());

1.全值匹配

2.最左前缀法则

如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。

虽然mysql会帮你调整顺序，但要浪费时间，不如自己在写sql就多考虑一些

3.不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描

这个要想到我们那个索引树，你用了函数了，我索引树都跟你这个值不一样，那肯定用不上索引啊

4.存储引擎不能使用索引中范围条件右边的列

第一个语句是能走的，为啥第二个不走？一般来说范围后面的索引会失效了

你看key_len才78，说明后面那个没用到，name长度是74，age长度是4，可以看key_len计算规则

5.尽量使用覆盖索引（只访问索引的查询（索引列包含查询列）），减少 select * 语句

6.mysql在使用不等于（！=或者<>），not in ，not exists 的时候无法使用索引会导致全表扫描

< 小于、 > 大于、 <=、>= 这些，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引

7.is null,is not null 一般情况下也无法使用索引

8.like以通配符开头（'$abc...'）mysql索引失效会变成全表扫描操作

9.字符串不加单引号索引失效

10.少用or或in，用它查询时，mysql不一定使用索引，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引，详见范围查询优化

11.范围查询优化

给年龄添加单值索引

索引优化课程总结【零散】

MySQL SQL语句的优化方法、表连接的底层算法及Count查询

分页SQL优化 ：
- 传统分页问题：传统分页SQL性能低，如翻到后面页数系统会变慢，因为它会查大量记录再舍弃前面的。
- 自增连续主键优化：若表数据按自增且连续的主键排序，可先计算某页前的数据，用ID大于该页开始的前一条记录，再用limit取记录，效率高，但需满足前提条件。
- 非自增连续主键优化：对于数据不一定连续且不按主键排序的场景，可用覆盖索引优化，先从表中按排序字段和limit查ID，再用临时表与主表关联，能提高效率。
表关联执行过程及算法 ：
- 嵌套循环连接算法（NLJ）：有索引关联时默认走此算法，先查小表T2，全表扫描拿出所有记录，再用关联条件去大表T1过滤，T1走索引，该SQL语句总共扫描约200行。
- 基于块的嵌套循环查询算法（BNL）：无索引关联时走此算法，先将小表T2数据放入join buffer，再从大表T1逐行取数据到join buffer比对，T2扫描100次，T1扫描1万次，内存过滤约100万次。
- 算法比较：无索引关联时BNL算法更快，因为磁盘扫描和内存计算数量级差异大；有索引时NLJ算法更高效。
- 表关联优化原则：关联字段尽量加索引，特别是被驱动表；让小表先执行驱动大表，若Mysql优化错可用straight join指定驱动表。
in和exists优化 ：
- 执行顺序：in相当于里面的先执行，得到结果后外面的SQL语句再与结果集关联；exists相当于先走外层，再拿外层结果集与里层结果集逐条关联判断是否存在。
- 优化原则：里面表结果集小用in；外面表小用exists，且exists尽量用join替代。
Count查询优化 ：
- 效率比较：在字段有索引的情况下，count(*)和count(1)差不多，大于count(字段)，大于count(主键)；字段无索引时，count(主键)比count(字段)快。
- 各类型原理：count(字段)扫描二级索引并拿出索引值计数；count(1)扫描二级索引，直接判断有索引就计数；count(*)做了特殊优化，按行累加。
- 不同引擎处理：Myisam存储引擎会维护表总数，查询效率高；Innodb因MVCC机制不维护，若对结果精度要求不高，可用SHOW TABLE STATUS查询不精确结果；若要精确结果，可将总数维护到Redis或数据库计数表。
阿里巴巴开发手册规范 ：
- 数据类型选择：小数类型尽量选Decimal，避免用float和double；定长字段用char，变长字段用varchar；时间类型用datetime。
- 单表数据量：单表行记录数尽量不超500万行或单表容量不超2G，否则考虑分库分表，但这只是推荐，可根据实际情况调整。
- 索引规约：业务上有唯一特性的字段，即使组合字段也推荐建唯一索引；禁止超过三个表的关联。

索引优化原则 - 范围查找与覆盖索引 ：
- 范围查找索引情况：范围查找可能走索引，如对加了索引的字段做范围查询，分析时可能认为走索引，但因数据量等因素实际可能不走，可将范围拆小优化。
- 覆盖索引使用：尽量使用覆盖索引，少用select *，查询字段尽量被联合索引覆盖，若无法覆盖，数据量大数据查找效率要求高时可考虑走搜索引擎。
索引优化原则 - 其他情况 ：
- 不等于与is null情况：不等于场景结果集可能太大，走索引用处不大，可能走全表扫描，但不同场景结果不同；is null和is not null一般情况下无法很好使用索引，索引树会集中存储null值。
- like查询优化：like查询中百分号在前无法走索引，因跳过部分字段后剩余部分无序；百分号在后能用索引，属于最左前缀原则，可优化为覆盖索引，减少查询字段，让结果集在一颗索引树中查找。
- 类型匹配与or、in使用：查询值与字段类型要匹配，类型不匹配可能做字段转换；or和in可能走索引也可能不走，与MySQL内部优化器数据检索比例表大小等因素有关，尽量少用，in的条数不宜太多。