SQL 的执行顺序,你搞清楚了吗?

2023-12-20 13:03:14

这是一条标准的查询语句:

这是我们实际上SQL执行顺序:

  • from 子句组装来自不同数据源的数据;
  • where 子句基于指定的条件对记录行进行筛选;
  • group by 子句将数据划分为多个分组;
  • 使用聚集函数进行计算;
  • 使用 having 子句筛选分组;
  • 计算所有的表达式;
  • select 的字段;
  • 使用 order by 对结果集进行排序。

SQL 语言不同于其他编程语言的最明显特征是处理代码的顺序。在大多数据库语言中,代码按编码顺序被处理。但在 SQL 语句中,第一个被处理的子句式 FROM,而不是第一出现的 SELECT。

SQL 查询处理的步骤:

  • FROM <left_table>
  • <join_type> JOIN <right_table>
  • ON <join_condition>
  • WHERE <where_condition>
  • GROUP BY <group_by_list>
  • WITH {CUBE | ROLLUP}
  • HAVING <having_condition>
  • SELECT (9) DISTINCT
  • ORDER BY <order_by_list>
  • <TOP_specification> <select_list>

以上每个步骤都会产生一个虚拟表,该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者(客户端应 用程序或者外部查询)不可用。只有最后一步生成的表才会会给调用者。如果没有在查询中指定某一个子句, 将跳过相应的步骤。

数据的关联过程

数据库中的两张表

from&join&where

用于确定我们要查询的表的范围,涉及哪些表。选择一张表,然后用join连接

from?table1?join?table2?on?table1.id=table2.id

选择多张表,用where做关联条件

from?table1,table2?where?table1.id=table2.id

我们会得到满足关联条件的两张表的数据,不加关联条件会出现笛卡尔积。

group by

按照我们的分组条件,将数据进行分组,但是不会筛选数据。比如我们按照即id的奇偶分组

having&where

having中可以是普通条件的筛选,也能是聚合函数。而where只能是普通函数,一般情况下,有having可以不写where,把where的筛选放在having里,SQL语句看上去更丝滑。

使用where再group by

先把不满足where条件的数据删除,再去分组

使用group by再having

先分组再删除不满足having条件的数据,这两种方法有区别吗,几乎没有!举个例子:100/2=50,此时我们把100拆分(10+10+10+10+10…)/2=5+5+5+…+5=50,只要筛选条件没变,即便是分组了也得满足筛选条件,所以where后group by 和group by再having是不影响结果的!不同的是,having语法支持聚合函数,其实having的意思就是针对每组的条件进行筛选。我们之前看到了普通的筛选条件是不影响的,但是having还支持聚合函数,这是where无法实现的。当前数据分组情况

执行having的筛选条件,可以使用聚合函数。筛选掉工资小于各组平均工资的having salary<avg(salary)

select

分组结束之后,我们再执行select语句,因为聚合函数是依赖于分组的,聚合函数会单独新增一个查询出来的字段,这里用紫色表示,这里我们两个id重复了,我们就保留一个id,重复字段名需要指向来自哪张表,否则会出现唯一性问题。最后按照用户名去重。

select?employee.id,distinct?name,salary,?avg(salary)

将各组having之后的数据再合并数据。

order by

最后我们执行order by 将数据按照一定顺序排序,比如这里按照id排序。如果此时有limit那么查询到相应的我们需要的记录数时,就不继续往下查了。

limit

记住limit是最后查询的,为什么呢?假如我们要查询年级最小的三个数据,如果在排序之前就截取到3个数据。实际上查询出来的不是最小的三个数据而是前三个数据了,记住这一点。我们如果limit 0,3窃取前三个数据再排序,实际上最少工资的是2000,3000,4000。你这里只能是4000,5000,8000了。

?

更多精彩内容,关注我们▼▼

文章来源:https://blog.csdn.net/m0_38048955/article/details/135099452
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。