文章插图
SQL 查询的执行顺序是怎样的?好像这个问题应该很好回答,毕竟自己已经写了无数个 SQL 查询了,有一些还很复杂的 。还装不了这个逼了?!
【SQL 查询语句先执行 SELECT?兄弟你认真的么?】
但事实是,我仍然很难确切地说出它的顺序是怎样的 。
言归正传,SELECT语句的完整语法如下:
1. SELECT 2. DISTINCT <select_list>3. FROM <left_table>4. <join_type> JOIN <right_table>5. ON <join_condition>6. WHERE <where_condition>7. GROUP BY <group_by_list>8. HAVING <having_condition>9. ORDER BY <order_by_condition>10.LIMIT <limit_number>
然而其执行顺序却是:FROM<表名> # 笛卡尔积ON<筛选条件> # 对笛卡尔积的虚表进行筛选JOIN <join, left join, right join...> <join表> # 指定join,用于添加数据到on之后的虚表中,例如left join会将左表的剩余数据添加到虚表中WHERE<where条件> # 对上述虚表进行筛选GROUP BY<分组条件> # 分组<SUM()等聚合函数> # 用于having子句进行判断,在书写上这类聚合函数是写在having判断里面的HAVING<分组筛选> # 对分组后的结果进行聚合筛选SELECT<返回数据列表> # 返回的单列必须在group by子句中,聚合函数除外DISTINCT# 数据除重ORDER BY<排序条件> # 排序LIMIT<行数限制>
其实,引擎在执行上述每一步时,都会在内存中形成一张虚拟表,然后对虚拟表进行后续操作,并释放没用的虚拟表的内存,以此类推 。具体解释:(注:下面“VT”表示 → 虚拟表 virtual )
- from:select * from table_1, table_2; 与 select * from table_1 join table_2; 的结果一致,都是表示求笛卡尔积;用于直接计算两个表笛卡尔积,得到虚拟表VT1,这是所有select语句最先执行的操作,其他操作时在这个表上进行的,也就是from操作所完成的内容
- on: 从VT1表中筛选符合条件的数据,形成VT2表;
- join: 将该 join 类型的数据补充到VT2表中,例如 left join 会将左表的剩余数据添加到虚表VT2中,形成VT3表;若表的数量大于2,则会重复1-3步;
- where: 执行筛选,(不能使用聚合函数)得到VT4表;
- group by: 对VT4表进行分组,得到VT5表;其后处理的语句,如select,having,所用到的列必须包含在group by条件中,没有出现的需要用聚合函数;
- having: 筛选分组后的数据,得到VT6表;
- select: 返回列得到VT7表;
- distinct: 用于去重得到VT8表;
- order by: 用于排序得到VT9表;
- limit: 返回需要的行数,得到VT10;
- group by条件中,每个列必须是有效列,不能是聚合函数;
- null值也会作为一个分组返回;
- 除了聚合函数,select子句中的列必须在group by条件中;
- 可以在 GRROUP BY 之后使用 WHERE 吗?(不行,GROUP BY 是在 WHERE 之后!)
- 可以对窗口函数返回的结果进行过滤吗?(不行,窗口函数是 SELECT 语句里,而 SELECT 是在 WHERE 和 GROUP BY 之后)
- 可以基于 GROUP BY 里的东西进行 ORDER BY 吗?(可以,ORDER BY 基本上是在最后执行的,所以可以基于任何东西进行 ORDER BY)
- LIMIT 是在什么时候执行?(在最后!)
SQL中的别名会影响SQL执行顺序么?如下方SQL所示:
SELECT CONCAT(first_name, ' ', last_name) AS full_name, count(*)FROM tableGROUP BY full_name
从这个语句来看,好像 GROUP BY 是在 SELECT 之后执行的,因为它引用了 SELECT 中的一个别名 。但实际上不一定要这样,数据库引擎会把查询重写成这样↓↓↓:SELECT CONCAT(first_name, ' ', last_name) AS full_name, count(*)FROM tableGROUP BY CONCAT(first_name, ' ', last_name)
所以,这样 GROUP BY 仍然先执行 。另外,数据库引擎还会做一系列检查,确保 SELECT 和 GROUP BY 中的东西是有效的,所以会在生成执行计划之前对查询做一次整体检查 。
数据库很可能不按正常顺序执行查询(优化)在实际当中,数据库不一定会按照 JOIN、WHERE、GROUP BY 的顺序来执行查询,因为它们会进行一系列优化,把执行顺序打乱,从而让查询执行得更快,只要不改变查询结果 。
推荐阅读
- 年薪近百万架构师,纯手写“满级”MySQL笔记,太全面了,已跪
- MySQL数据引擎,12缸就是猛
- 淘宝违禁词查询在线 淘宝哪些词属于违禁词
- 8个SQL错误:您是否犯了这些错误?
- MYSQL 由一个锁问题,带出MYSQL事务错误不回滚的问题
- 常见分布式锁实现方式
- MySQL压力测试工具,值得收藏
- MySQL 子查询优化
- MySQL Binlog 技术原理和业务应用案例分析
- 三国演义小说中最精辟的语句大全