explain说明
EXPLAIN是MySQl必不可少的一个分析工具，主要用来测试sql语句的性能及对sql语句的优化，或者说模拟优化器执行SQL语句。 在select语句之前增加explain关键字，执行后MySQL就会返回执行计划的信息
而不是执行sql。但如果from中包含子查询，MySQL仍会执行该子查询，并把子查询的结果放入临时表中。
它显示了mysql如何使用索引来处理select语句以及连接表，可以帮助选择更好的索引和写出更优化的查询语句
创建几个个简单的表做关联用来演示
user表
DROP TABLE IF EXISTS `upms_user`;
CREATE TABLE `upms_user` (
`user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
`username` varchar(64) DEFAULT NULL COMMENT '用户名',
`password` varchar(255) DEFAULT NULL COMMENT '密码',
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=40 DEFAULT CHARSET=utf8mb4;
role表
DROP TABLE IF EXISTS `upms_role`;
CREATE TABLE `upms_role` (
`role_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
`role_name` varchar(64) DEFAULT NULL COMMENT '角色名称',
`role_code` varchar(64) DEFAULT NULL COMMENT '角色编码',
`role_desc` varchar(255) DEFAULT NULL COMMENT '角色描述',
`tenant_id` int(5) DEFAULT '1' COMMENT '租户id',
PRIMARY KEY (`role_id`)
) ENGINE=InnoDB AUTO_INCREMENT=42 DEFAULT CHARSET=utf8mb4;
user_role表
DROP TABLE IF EXISTS `upms_user_role`;
CREATE TABLE `upms_user_role` (
`user_id` int(11) NOT NULL COMMENT '用户ID',
`role_id` int(11) NOT NULL COMMENT '角色ID',
PRIMARY KEY (`user_id`,`role_id`),
KEY `user_id` (`user_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
执行一个简单关联查询查看explain 查看都有哪些列
EXPLAIN SELECT
*
FROM
upms_user USER
INNER JOIN upms_user_role urole ON USER .user_id = urole.user_id
INNER JOIN upms_role role ON role.role_id = urole.role_id
执行结果
可以看见一共以下列：
id: 选择标识符 select_type: 查询类型
table: 输出结果集的表
partitions: 匹配的分区
type: 表的连接类型
possible_keys: 查询时可能使用的索引
key: 实际使用的索引
key_len: 索引字段的长度
ref: 列与索引的比较
rows: 扫描出的行数 filtered: 按表条件过滤的行百分比
extra: 执行情况描述和说明
结合sql对每列进行详细说明
id列
id列的编号是select的序列号，有几个select就有几个id，并且id的顺序是按select出现的顺序增长的。
id越大执行优先级越高，id相同则从上往下执行，id为NULL最后执行
id相同的情况下
一般都是直接关联查询，id相同从上往下执行
id不同的情况下
一般就是带有from 查询或者子查询等明确循序的sql,id越大，执行优先级越高
select type列，select type表示对应行是简单还是复杂的查询。
simple：简单查询。查询不包含子查询和union。
还是拿刚才的sql例子，执行后发现都是simple,因为没有子查询和union如下
primary：复杂查询中最外层的select
subquery：包含在select中的子查询
不在from子句中,实际测试在from中的也会被标记subquery
derived：包含在from子句中的子查询(实际)。MySQL会将结果存放在一个临时表中，也称为派生表。
实际测试在from中的也会被标记subquery*
union：在union关键字随后的selelct。
会先执行uinon 后面的select 语句然后结果再执行union 前面的select 结果最后汇总
table列
这一列表示explain的一行正在访问哪个表。
当from子句中有子查询时，table列是格式，表示当前查询依赖id=N的查询，于是先执行id=N的查询。
当有union时，UNION RESULT的table列的值为<union 1,2>，1和2表示参与union的select行id。
type列（重点，关系到是否用了索引以及索引类型，用来优化查询）
这一列表示关联类型或访问类型，即MySQL决定如何查找表中的行，查找数据行对应的大概范围。 依次从最优到最差的分别为：system>const>eq_ref>ref>range>index>All
一般来说，得保证查询达到range级别，最好达到ref。
NULL：MySQL能够在优化阶段分解查询语句，在执行阶段用不着在访问表或索引。例如：在索引列中选取最小值，可以单独查找索引来完成，不需在执行时访问表
type 类型列举排序说明
主要有如下类型：
system
const
eq_ref
ref
range
index
All
这一列表示关联类型或访问类型，即MySQL决定如何查找表中的行，查找数据行对应的大概范围。
依次从最优到最差的分别为：system>const>eq_ref>ref>range>index>All
一般来说，得保证查询达到range级别，最好达到ref。
const、system （其实可以认为是一个，system表示表里只有一行数据的时候的const）
用于primay key或unique key的所有列与常数比较时，所以表最多有一个匹配行，读取1次，速读较快。system 是const的特例，表中只有一行元素匹配时为system
这里直接用了主键去查所以是const,如果表里只有一条数据，那么就是system,unique key效果是一样的
eq_ref（一般都是带有关联查询且最多返回一条，情况很少，暂时忽略）
primay key或 unique key索引的所有部分被连接使用，最多只会返回一条符合条件的记录。这可能是const之外最好的联接类型，简单的select查询不会出现这种type
ref（常规长训场景最好达到此索引级别）
相比eq_ref，不适用唯一索引，而是使用普通索引或者唯一索引的部分前缀，索引要和某个值相比较，可能会找到多个符合条件的行。 简单select查询，name是普通索引（非主键索引或唯一索引）
这种关联查询比较常见，基本上是关联用到了普通索引
range（比较常见，比如集合内，日期区间查询等）
范围扫描通常出现在in(), between,>,<,>=等操作中。使用一个索引来检索给定范围的行。
index（基本上是无条件查询，但是查询内容是索引）
index：扫描全表索引，通常比All快一些
all：（全表扫描，一般很可能意味着需要优化了）
上面的查询索引字段变为 即没用到索引，则走了全表扫描*
possible_keys列（不是一定准确的）
这一列显示select可能会使用哪些查询来查找。
key列（实际准确用到的）
这一列显示MySQL实际采用哪个索引对该表的访问。
如果没有使用索引，则改列为NULL
key_len列
这一列显示了mysql在索引里使用的字节数，通过这个值可以估算出具体使用了索引中的哪些列。
ref列
这一列显示了在key列记录的索引中，表查找值所用到的列或常量，常见的有： const(常量)，字段名等
row列（读取并检测的行数，注意这个不是结果集的行数）
Extra列（额外信息）
包含内容如下：
Using index：使用覆盖索引（结果集的字段是索引，即select后的film_id）
Using index condition：查询的列不完全被索引覆盖，where条件中是一个前导的范围
Using where：使用where语句来处理结果，查询的列未被索引覆盖
Using where：使用where语句来处理结果，查询的列未被索引覆盖
Using temporary：mysql需要创建一张临时表来处理查询。出现这种情况一般要进行优化，首先要想到是索引优化。
常用优化方法
1、选取最适用的字段属性
2、使用连接（JOIN）来代替子查询(Sub-Queries)
3、使用联合(UNION)来代替手动创建的临时表
索引何时应该使用
需创建索引的情况：
1.主键，自动建立唯一索引
2.频繁作为查询的条件的字段
3.查询中与其他表关联的字段存在外键关系
4.查询中排序的字段，排序字段若通过索引去访问将大大提高排序的速度
5.查询中统计或者分组字段 避免创建索引的情况：
1.数据唯一性差的字段不要使用索引 比如性别，只有两种可能数据。意味着索引的二叉树级别少，多是平级。这样的二叉树查找无异于全表扫描。
2.频繁更新的字段不要使用索引 比如登录次数，频繁变化导致索引也频繁变化，增大数据库工作量，降低效率。
3.字段不在where语句出现时不要添加索引 只有在where语句出现，mysql才会去使用索引
4.数据量少的表不要使用索引 使用了改善也不大 三、哪些sql能命中索引
1.前导模糊查询不能使用索引，如name like ‘%nowjava’ 2、Union、in、or可以命中索引，建议使用in。 3、负条件查询不能使用索引，可以优化为in查询，其中负条件有！=、<>、not in、not exists、not like等
4、联合索引最左前缀原则，又叫最左侧查询，如果在（a，b，c）三个字段上建立联合索引，那么它能够加快a|（a，b）|（a，b，c）三组的查询速度。
5、建立联合查询时，区分度最高的字段在最左边
6、如果建立了（a，b）联合索引，就不必再单独建立a索引。同理，如果建立了（a，b，c）索引就不必再建立a，（a，b）索引
7、存在非等号和等号混合判断条件时，在建索引时，要把等号条件的列前置 8、范围列可以用到索引，但是范围列后面的列无法用到索引。
索引最多用于一个范围列，如果查询条件中有两个范围列则无法全用到索引。范围条件有：<、<=、>、>=、between等。
9、把计算放到业务层而不是数据库层。在字段上计算不能命中索引， 10、强制类型转换会全表扫描，
如果phone字段是varcher类型，则下面的SQL不能命中索引。Select * from user where
phone=1380000000 11、更新十分频繁、数据区分度不高的字段上不宜建立索引。
更新会变更B+树，更新频繁的字段建立索引会大大降低数据库性能。
“性别”这种区分度不太大的属性，建立索引是没有什么意义的，不能有效过滤数据，性能与全表扫描类似。
一般区分度在80%以上就可以建立索引。区分度可以使用count（distinct（列名））/count（）来计算。
12、利用覆盖索引来进行查询操作，避免回表。
被查询的列，数据能从索引中取得，而不是通过定位符row-locator再到row上获取，即“被查询列要被所建的索引覆盖”，这能够加速度查询。
13、建立索引的列不能为null，使用not null约束及默认值 14、利用延迟关联或者子查询优化超多分页场景，
MySQL并不是跳过offset行，而是取offset+N行，然后放弃前offset行，返回N行，那当offset特别大的时候，效率非常低下，要么控制返回的总数，要么对超过特定阈值的页进行SQL改写。
15、业务上唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。
16、超过三个表最好不要用join，需要join的字段，数据类型必须一致，多表关联查询时，保证被关联的字段需要有索引。
17、如果明确知道查询结果只要一条，limit 1能够提高效率，比如验证登录的时候。 18、Select语句务必指明字段名称
19、如果排序字段没有用到索引，就尽量少排序 20、尽量用union all 代替
union。Union需要将集合合并后在进行唯一性过滤操作，这会涉及到排序，大量的cpu运算，加大资源消耗及延迟，当然，使用union
all的前提条件是两个结果集没有重复数据。*