SQL优化
执行计划,表关联查询顺序,优化策略与思路
MYSQL执行过程
一、MySQL架构总览：
二、查询执行流程
下面再向前走一些，容我根据自己的认识说一下查询执行的流程是怎样的：
1.连接
1.1客户端发起一条Query请求，监听客户端的‘连接管理模块’接收请求
1.2将请求转发到‘连接进/线程模块’
1.3调用‘用户模块’来进行授权检查
1.4通过检查后，‘连接进/线程模块’从‘线程连接池’中取出空闲的被缓存的连接线程和客户端请求对接，如果失败则创建一个新的连接请求
2.处理
2.1先查询缓存，检查Query语句是否完全匹配，接着再检查是否具有权限，都成功则直接取数据返回
2.2上一步有失败则转交给‘命令解析器’，经过词法分析，语法分析后生成解析树
2.3接下来是预处理阶段，处理解析器无法解决的语义，检查权限等，生成新的解析树
2.4再转交给对应的模块处理
2.5如果是SELECT查询还会经由‘查询优化器’做大量的优化，生成执行计划
2.6模块收到请求后，通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限
2.7有则调用‘表管理模块’，先是查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件
2.8根据表的meta数据，获取表的存储引擎类型等信息，通过接口调用对应的存储引擎处理
2.9上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中
3.结果
3.1Query请求完成后，将结果集返回给‘连接进/线程模块’
3.2返回的也可以是相应的状态标识，如成功或失败等
3.3‘连接进/线程模块’进行后续的清理工作，并继续等待请求或断开与客户端的连接
三、SQL解析顺序
接下来再走一步，让我们看看一条SQL语句的前世今生。
首先看一下示例语句
示例语句
SELECT DISTINCT
< select_list >
FROM
< left_table > < join_type >
JOIN < right_table > ON < join_condition >
WHERE
< where_condition >
GROUP BY
< group_by_list >
HAVING
< having_condition >
ORDER BY
< order_by_condition >
LIMIT < limit_number >
执行顺序
FROM
ON
JOIN
WHERE
GROUP BY
HAVING
SELECT
DISTINCT
ORDER BY
LIMIT
SQL解析
1. FROM
当涉及多个表的时候，左边表的输出会作为右边表的输入，之后会生成一个虚拟表VT1。
(1-J1)笛卡尔积
计算两个相关联表的笛卡尔积(CROSS JOIN) ，生成虚拟表VT1-J1。
mysql> select * from table1,table2;
+-----+------+-----+------+
| uid | name | oid | uid |
+-----+------+-----+------+
| aaa | mike | 1 | aaa |
| bbb | jack | 1 | aaa |
| ccc | mike | 1 | aaa |
| ddd | mike | 1 | aaa |
| aaa | mike | 2 | aaa |
| bbb | jack | 2 | aaa |
| ccc | mike | 2 | aaa |
| ddd | mike | 2 | aaa |
| aaa | mike | 3 | bbb |
| bbb | jack | 3 | bbb |
| ccc | mike | 3 | bbb |
| ddd | mike | 3 | bbb |
| aaa | mike | 4 | bbb |
| bbb | jack | 4 | bbb |
| ccc | mike | 4 | bbb |
| ddd | mike | 4 | bbb |
| aaa | mike | 5 | bbb |
| bbb | jack | 5 | bbb |
| ccc | mike | 5 | bbb |
| ddd | mike | 5 | bbb |
| aaa | mike | 6 | ccc |
| bbb | jack | 6 | ccc |
| ccc | mike | 6 | ccc |
| ddd | mike | 6 | ccc |
| aaa | mike | 7 | NULL |
| bbb | jack | 7 | NULL |
| ccc | mike | 7 | NULL |
| ddd | mike | 7 | NULL |
+-----+------+-----+------+
28 rows in set (0.00 sec)
两次全表扫描
哈希索引,查找复杂度都是O(1)。
2. WHERE
对VT1过程中生成的临时表进行过滤，满足WHERE子句的列被插入到VT2表中。
注意：
此时因为分组，不能使用聚合运算；也不能使用SELECT中创建的别名；
与ON的区别：
如果有外部列，ON针对过滤的是关联表，主表（保留表）会返回所有的列；
如果没有添加外部列，两者的效果是一样的；
应用：
对主表的过滤应该放在WHERE；
对于关联表，先条件查询后连接则用ON，先连接后条件查询则用WHERE；
若是是左连接,on 只过滤与主表关联的数据,不会减少实际的查询内容, WHERE之后才是过滤整体结果的数量
mysql> SELECT
-> *
-> FROM
-> table1 AS a
-> LEFT OUTER JOIN table2 AS b ON a.uid = b.uid
-> WHERE
-> a. NAME = 'mike';
+-----+------+------+------+
| uid | name | oid | uid |
+-----+------+------+------+
| aaa | mike | 1 | aaa |
| aaa | mike | 2 | aaa |
| ccc | mike | 6 | ccc |
| ddd | mike | NULL | NULL |
+-----+------+------+------+
4 rows in set (0.00 sec)
hash join 哈希连接 驱动表和被驱动表都只会访问0次或1次
应用场景:一个大表一个小表/表上没有索引/返回结果集比较大
3. GROUP BY
这个子句会把VT2中生成的表按照GROUP BY中的列进行分组。生成VT3表。
注意：
其后处理过程的语句，如SELECT,HAVING，所用到的列必须包含在GROUP BY中，对于没有出现的，得用聚合函数；
原因：
GROUP BY改变了对表的引用，将其转换为新的引用方式，能够对其进行下一级逻辑操作的列会减少；
原作者的理解是：
根据分组字段，将具有相同分组字段的记录归并成一条记录，因为每一个分组只能返回一条记录，除非是被过滤掉了，而不在分组字段里面的字段可能会有多个值，多个值是无法放进一条记录的，所以必须通过聚合函数将这些具有多值的列转换成单值；
查找列要小于分组列, SELECT a.* GROUP BY a.uid 是没有问题的,若 GROUP BY a.name就不行了
mysql> SELECT
-> a.*
-> FROM
-> table1 AS a
-> LEFT OUTER JOIN table2 AS b ON a.uid = b.uid
-> WHERE
-> a. NAME = 'mike'
-> GROUP BY
-> a.uid;
+-----+------+
| uid | name |
+-----+------+
| aaa | mike |
| ccc | mike |
| ddd | mike |
+-----+------+
3 rows in set (0.00 sec)
GROUP BY 重新聚合查询
4. HAVING
这个子句对VT3表中的不同的组进行过滤，只作用于分组后的数据，满足HAVING条件的子句被加入到VT4表中。
mysql> SELECT
-> *
-> FROM
-> table1 AS a
-> LEFT OUTER JOIN table2 AS b ON a.uid = b.uid
-> WHERE
-> a. NAME = 'mike'
-> GROUP BY
-> a.uid
-> HAVING
-> count(b.oid) < 2;
+-----+------+------+------+
| uid | name | oid | uid |
+-----+------+------+------+
| ccc | mike | 6 | ccc |
| ddd | mike | NULL | NULL |
+-----+------+------+------+
2 rows in set (0.00 sec)
7.LIMIT
LIMIT子句从上一步得到的VT6虚拟表中选出从指定位置开始的指定行数据。
注意：
offset和rows的正负带来的影响；
当偏移量很大时效率是很低的，可以这么做：
采用子查询的方式优化，在子查询里先从索引获取到最大id，然后倒序排，再取N行结果集
采用INNER JOIN优化，JOIN子句里也优先从索引获取ID列表，然后直接关联查询获得最终结果
查询主键排序, 通过主键作为其他查询的入参来提高效率
mysql> SELECT
-> a.uid,
-> count(b.oid) AS total
-> FROM
-> table1 AS a
-> LEFT JOIN table2 AS b ON a.uid = b.uid
-> WHERE
-> a. NAME = 'mike'
-> GROUP BY
-> a.uid
-> HAVING
-> count(b.oid) < 2
-> ORDER BY
-> total DESC
-> LIMIT 1;
+-----+-------+
| uid | total |
+-----+-------+
| ccc | 1 |
+-----+-------+
1 row in set (0.00 sec)
执行计划分析
SELECT
a.uid,
count(b.oid) AS total
FROM
table1 AS a
LEFT JOIN table2 AS b ON a.uid = b.uid
WHERE
a. NAME = 'mike'
GROUP BY
a.uid
HAVING
count(b.oid) < 2
ORDER BY
total DESC
LIMIT 1;
当前未用到索引,
三次full scan , table1 AS a / table2 AS b / GROUP BY
SELECT
a.*
FROM
table1 AS a
LEFT JOIN table2 AS b ON a.uid = b.uid
WHERE
a. NAME = 'mike'
GROUP BY
a.uid
HAVING
count(b.oid) < 2
sql优化
尽量少做重复的工作
控制同一语句的多次执/减少多次的数据转换/
杜绝不必要的子查询和连接表，子查询在执行计划一般解释成外连接，多余的连接表带来额外的开销
关于临时表和表变量的选择
临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择，一般情况下，SELECT INTO会比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO会锁定TEMPDB的系统表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用户并发环境下，容易阻塞其他进程，所以建议，在并发系统中，尽量使用CREATE TABLE + INSERT INTO，而大数据量的单个语句使用中，使用SELECT INTO。
子查询的用法
相关子查询可以用IN、NOT IN、EXISTS、NOT EXISTS引入
NOT IN、NOT EXISTS的相关子查询可以改用LEFT JOIN代替写法
SELECT PUB_NAME FROM PUBLISHERS
WHERE PUB_ID NOT IN
(SELECT PUB_ID FROM TITLES
WHERE TYPE = 'BUSINESS')
--可以改写成：
SELECT A.PUB_NAME FROM PUBLISHERS A
LEFT JOIN TITLES B ON B.TYPE = 'BUSINESS' AND A.PUB_ID=B. PUB_ID
WHERE B.PUB_ID IS NULL
SELECT TITLE FROM TITLES
WHERE NOT EXISTS
(SELECT TITLE_ID FROM SALES
WHERE TITLE_ID = TITLES.TITLE_ID)
可以改写成：
SELECT TITLE
FROM TITLES
LEFT JOIN SALES ON SALES.TITLE_ID = TITLES.TITLE_ID
WHERE SALES.TITLE_ID IS NULL
如果保证子查询没有重复 ，IN、EXISTS的相关子查询可以用INNER JOIN 代替
SELECT PUB_NAME FROM PUBLISHERS
WHERE PUB_ID IN
(SELECT PUB_ID FROM TITLES
WHERE TYPE = 'BUSINESS')
可以改写成：
SELECT A.PUB_NAME --SELECT DISTINCT A.PUB_NAME
FROM PUBLISHERS A
INNER JOIN TITLES B
ON B.TYPE = 'BUSINESS' AND A.PUB_ID=B. PUB_ID
IN``的相关子查询用EXISTS代替
SELECT PUB_NAME FROM PUBLISHERS
WHERE PUB_ID IN
(SELECT PUB_ID FROM TITLES WHERE TYPE = 'BUSINESS')
--可以用下面语句代替：
SELECT PUB_NAME FROM PUBLISHERS
WHERE EXISTS
(SELECT 1 FROM TITLES
WHERE TYPE = 'BUSINESS' AND PUB_ID= PUBLISHERS.PUB_ID)
不要用COUNT(*)的子查询判断是否存在记录，最好用LEFT` `JOIN或者EXISTS，比如有人写这样的语句：
SELECT JOB_DESC FROM JOBS
WHERE (SELECT COUNT(*) FROM EMPLOYEE
WHERE JOB_ID=JOBS.JOB_ID)=0
--应该改成：
SELECT JOBS.JOB_DESC FROM JOBS
LEFT JOIN EMPLOYEE ON EMPLOYEE.JOB_ID=JOBS.JOB_ID
WHERE EMPLOYEE.EMP_ID IS NULL
SELECT JOB_DESC FROM JOBS
WHERE (SELECT COUNT(*) FROM EMPLOYEE
WHERE JOB_ID=JOBS.JOB_ID)<>0
--应该改成：
SELECT JOB_DESC FROM JOBS
WHERE EXISTS (SELECT 1 FROM EMPLOYEE WHERE JOB_ID=JOBS.JOB_ID)
建立索引后，并不是每个查询都会使用索引，在使用索引的情况下，索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引，
不要对索引字段进行运算，而要想办法做变换
SELECT ID FROM T WHERE NUM/2=100
应改为:
SELECT ID FROM T WHERE NUM=100*2
SELECT ID FROM T WHERE NUM/2=NUM1
如果NUM有索引应改为:
SELECT ID FROM T WHERE NUM=NUM1*2
如果NUM1有索引则不应该改。
不要对索引字段进行格式转换
不要对索引字段使用函数
不要对索引字段进行多字段连接
join
join关联查询的计算是很复杂的，特别是数据量比较大的情况下，实际情况还是拆解较快的
Join拆解的核心就是利用In关键字
要么用空间换时间，要么用时间换空间
多表连接的连接条件对索引的选择有着重要的意义，所以我们在写连接条件条件的时候需要特别注意。
A、多表连接的时候，连接条件必须写全，宁可重复，不要缺漏。
B、连接条件尽量使用聚集索引
C、注意ON、WHERE和HAVING部分条件的区别
ON是最先执行， WHERE次之，HAVING最后，因为ON是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，WHERE也应该比 HAVING快点的，因为它过滤数据后才进行SUM，在两个表联接时才用ON的，所以在一个表的时候，就剩下WHERE跟HAVING比较了
考虑联接优先顺序：
(1)INNER JOIN
(2)LEFT JOIN (注：RIGHT JOIN 用 LEFT JOIN 替代)
(3)CROSS JOIN
索引
索引并不适用于所有情况：a.少量数据；b.频繁进行改动的字段，不适合做索引；c.很少使用的字段，不需要加索引
索引会提高数据查询效率，但是会降低“增、删、改”的效率。当不使用索引的时候，我们进行数据的增删改，只需要操作源表即可，但是当我们添加索引后，不仅需要修改源表，也需要再次修改索引，很麻烦。
先执行顺序, 是否走索引, 有无类型转换
参考文章:
18000 字的SQL优化大全
步步深入：MySQL架构总览->查询执行流程->SQL解析顺序
MySQL索引总结（4）——btree与hash区别