sql性能优化原理（explain的参数分析）

sql执行计划：

explain:
可以模拟sql优化器执行sql语句，从而让开发人员知道自己的sql情况
优化方法 官网：optimization.html

explain使用:
explain + sql 语句

select t.* from teacher t,course c,teacherCart tc where …
explain的类型分析:

① id:
id值相同，从上往下顺序执行；查询表顺序，表数据条数由少到多执行（笛卡尔积）
id不同，从内查到外层，id值越大越先查询
id相同又有不同，先大后小，相同部分，从上往下
②select_type
查询类型
primary 主查询
subquery 子查询
simple 简单查询
derived 衍生查询，使用到临时表
selec cname from(select…);
有union表，左边就是衍生表
③table 表格
④type 索引类型
system>const>eq_ref>ref>range>index>all
system 只有一条数据
const 仅仅能查到一条数据的SQL，用于主键和唯一键
eq_ref 唯一性索引，对于每个索引键的查询，返回匹配伟一行数据（有且只有一个）
常见于唯一索引和主键索引
ref：非唯一性索引，返回匹配所有行
range：where 后面是一个范围查询
in, between and
index:查询索引列
all：查询所有数据（不是索引就要全表扫描，扫描全部的数据）
⑤possible_keys
可能用到的索引 null/索引列，预测有时候是不准的，正常现象
⑥key
实际使用到的索引 null说明没有用索引
⑦key_len
索引长度。用于判断符合索引是否被完全使用，复合索引是用了几层索引。
utf8一个字符占用3个字节，如果索引字段为null则会使用一个字节进行标识
1（null） 2（字段可变长度）
⑧ref
注意区分，指明当前表所参照的字段（const）
⑨rows
被索引优化查询的 数据个数（行数）
⑩extra
using filesort
性能消耗大，需要额外进行一次排序排序之前先查找，排序和查找则不会出现上述错误。最佳左前缀，不跨列。 where和order by安装复合索引顺序使用，不要跨列或无序使用
using temporary
性能损耗大，用到了临时表常见于order by，已经存在一张表但是不适用
查询列跟分组的列名相同
using index
索引覆盖，性能提升；原因在于 不读取源文件，只从索引文件中获取数据（不需要回表查询）
using where
需要回表查询 where后面的条件列不在索引列之中
impossible where
where 子句永远不可能

实际情况只能达到 ref>range ，另外sql查询自带优化会干扰我们的优化。