背景：
最近在公司遇到一个业务场景的查询优化，也就2000条的数据查询竟然要两分多种（慢出天际），但是这条sql业务上也没有什么错误。于是苦事冥想开始想怎么优化它！同时做个笔记，加强记忆。
想要优化一条sql首先得知道 它的基本执行时怎么样？
sql的解析顺序
select [distinct]
from
left join
on
where
group by
having
union
order by
limit
上面是一条查询sql的基本语法，下面就是mysql的对这个条查询sql的执行顺序
-
执行 FROM 语句，
mysql是从左往右执行，oracle是从右往左执行， SQL语句的执行过程中，都会产生一个虚拟表，用来保存SQL语句的执行结果（这是重点），执行from语句之后会产生一个虚拟表暂时叫VT1（vitual table 1），VT1是根据笛卡尔积生成（注：个人理解笛卡尔积 就是两个集合相乘的结果）
-
执行on进行过滤
根据on后面的条件过滤掉不符合条件的数据，产生VT2
-
执行链接的类型
inner join内连接、left join左链接、right右链接、outer join 外链接、full outer join 全连接
执行完产生VT3
-
执行where后面的条件
这时候使用WHERE条件的时候要注意：不能使用组函数、并且字段的别名不能放到条件中使用
例如SELECT city as c FROM t WHERE c='shanghai'
-
执行group by 进行分组
-
执行having过滤
HAVING
子句主要和GROUP BY子句配合使用，having后面可以跟组函数的条件 -
执行select
-
执行distinct，去掉重复的数据
-
执行order by 语句排序
-
执行分页语句
from
on
join
where
group by
having
select
distinct
union
order by
这里就基本能知道sql是怎么执行的了。
但是这样还是不够直观，对于定位低效率的sql语句帮助不是很明显，那么查看执行计划是个好办法。
查看执行计划：
EXPLAIN
只用把这个关键词放在sql语句的前面即可，效果如下：
image-20180825173048716.png
explain的列解释：
id：代表执行顺序 ,id值相同执行顺序从上到下，id值相同执行顺序从上到下。
select_type：代表对应行是简单还是复杂SELECT。
SIMPLE：不包含子查询/union操作的查询
PRIMARY：查询中如果包含了子查询，那么外层的查询标记为PRIMARY
SUBQUERY：select列表的中的子查询
DEPENDEN SUBQUERY：依赖外部结果的子查询
table：输出数据行所在的表名
PARTITIONS：对于分区表，显示查询的分区ID，对于非分区表，显示为NULL
type：这是重要的列,显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL
possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。
key:实际使用的索引。如果为NULL，则没有使用索引。
key_len:使用的索引的长度。在不损失精确性的情况下，长度越短越好。
ref:显示索引的哪一列被使用了,如果可能的话，是一个常数
rows：MYSQL认为必须检查的用来返回请求数据的行数，ROWS值的大小是个统计抽样结果，并不十分准确
Filtered：表示返回结果的行数占需读取行数的百分比，Filter列的值越大越好
extra：包含查询mysql解决查询的详细信息。
到这里一个sql语句出来，那么可很直观的定位出哪里太慢了？有没有用到索引？用了那个索引？等等
接下里就可以把一些sql技巧开始应用起来了
sql技巧：
-
避免SELECT *，
-
越小的列会越快
-
避免多个范围条件
实际开发中，我们会经常使用多个范围条件，比如想查询某个时间段内登录过的用户：
select user.* from user where login_time > '2017-04-01' and age between 18 and 30;这个查询有一个问题：它有两个范围条件，login_time列和age列，MySQL可以使用login_time列的索引或者age列的索引，但无法同时使用它们。
待完善………………
MySQL查询过程
image-20180825190240127.png
网友评论