SQL:WHERE 和 HAVING、ON 有什么区别?
ccwgpt 2024-12-12 11:11 38 浏览 0 评论
QL 提供了多种对数据进行过滤的方式,包括WHERE、HAVING以及ON子句等。虽然它们都能够实现类似的功能,但是你知道它们之间的区别吗?让我们一起来探讨一下。
除非特殊说明,以下内容适用于各种数据库,包括 MySQL、Oracle、SQL Server、PostgreSQL 以及 SQLite 等;其中的示例表和数据来源于 GitHub。
WHERE 与 HAVING
WHERE与HAVING的根本区别在于:
WHERE子句在GROUP BY分组和聚合函数之前对数据行进行过滤;
HAVING子句对GROUP BY分组和聚合函数之后的数据行进行过滤。
因此,WHERE子句中不能使用聚合函数。例如,以下语句将会返回错误:
-- 查找人数大于 5 的部门
select dept_id, count(*)
from employee
where count(*) > 5
group by dept_id;
由于在执行WHERE子句时,还没有计算聚合函数 count(*),所以无法使用。正确的方法是使用HAVING对聚合之后的结果进行过滤:
-- 查找人数大于 5 的部门
select dept_id, count(*)
from employee
group by dept_id
having count(*) > 5;
dept_id|count(*)|
-------|--------|
4| 9|
5| 8|
另一方面,HAVING子句中不能使用除了分组字段和聚合函数之外的其他字段。例如,以下语句将会返回错误:
-- 统计每个部门月薪大于等于 30000 的员工人数
select dept_id, count(*)
from employee
group by dept_id
having salary >= 30000;
因为经过GROUP BY分组和聚合函数之后,不再存在 salary 字段,HAVING子句中只能使用分组字段或者聚合函数。
??SQLite 虽然允许HAVING子句中出现其他字段,但是得到的结果不正确。
从性能的角度来说,HAVING子句中如果使用了分组字段作为过滤条件,应该替换成WHERE子句;因为WHERE可以在执行分组操作和计算聚合函数之前过滤掉不需要的数据,性能会更好。下面示例中的语句 1 应该替换成语句 2:
-- 语句 1
select dept_id, count(*)
from employee
group by dept_id
having dept_id = 1;
-- 语句 2
select dept_id, count(*)
from employee
where dept_id = 1
group by dept_id;
当然,WHERE和HAVING可以组合在一起使用。例如:
select dept_id, count(*)
from employee
where salary > 10000
group by dept_id
having count(*) > 1;
dept_id|count(*)|
-------|--------|
1| 3|
该语句返回了月薪大于 10000 的员工人数大于 1 的部门;WHERE用于过滤月薪大于 10000 的员工;HAVING用于过滤员工数量大于 1 的部门。
WHERE 与 ON
当查询涉及多个表的关联时,我们既可以使用WHERE子句也可以使用ON子句指定连接条件和过滤条件。这两者之间的主要区别在于:
对于内连接(inner join)查询,WHERE和ON中的过滤条件等效;
对于外连接(outer join)查询,ON中的过滤条件在连接操作之前执行,WHERE中的过滤条件(逻辑上)在连接操作之后执行。
对于内连接查询而言,以下三个语句的结果相同:
-- 语句 1
select d.dept_name, e.emp_name, e.sex, e.salary
from employee e, department d
where e.dept_id = d.dept_id
and e.emp_id = 10;
dept_name|emp_name|sex|salary |
---------|--------|---|-------|
研发部 |廖化 |男 |6500.00|
-- 语句 2
select d.dept_name, e.emp_name, e.sex, e.salary
from employee e
join department d on (e.dept_id = d.dept_id and e.emp_id = 10);
dept_name|emp_name|sex|salary |
---------|--------|---|-------|
研发部 |廖化 |男 |6500.00|
-- 语句 3
select d.dept_name, e.emp_name, e.sex, e.salary
from employee e
join department d on (e.dept_id = d.dept_id)
where e.emp_id = 10;
dept_name|emp_name|sex|salary |
---------|--------|---|-------|
研发部 |廖化 |男 |6500.00|
语句 1 在WHERE中指定连接条件和过滤条件;语句 2 在ON中指定连接条件和过滤条件;语句 3 在ON中指定连接条件,在WHERE中指定其他过滤条件。上面语句不但结果相同,数据库的执行计划也相同。以 MySQL 为例,以上语句的执行计划如下:
id|select_type|table|partitions|type |possible_keys |key |key_len|ref |rows|filtered|Extra|
--|-----------|-----|----------|-----|--------------------|-------|-------|-----|----|--------|-----|
1|SIMPLE |e | |const|PRIMARY,idx_emp_dept|PRIMARY|4 |const| 1| 100| |
1|SIMPLE |d | |const|PRIMARY |PRIMARY|4 |const| 1| 100| |
尽管如此,仍然建议将两个表的连接条件放在ON子句中,将其他过滤条件放在WHERE子句中;这样语义更加明确,更容易阅读和理解。对于上面的示例而言,推荐使用语句 3 的写法。
对于外连接而言,连接条件只能用ON子句表示,因为WHERE子句无法表示外连接的语义。例如:
select d.dept_name, e.emp_name, e.sex, e.salary
from department d
left join employee e on (e.dept_id = d.dept_id)
where d.dept_name = '保卫部';
dept_name|emp_name|sex|salary|
---------|--------|---|------|
保卫部 | | | |
由于“保卫部”没有员工,我们需要使用外连接返回部门的信息;WHERE条件用于过滤 dept_id = 6 的数据;此时,员工表中返回的都是 NULL。
Oracle 支持在WHERE子句的右/左侧使用 (+) 表示左/右外连接,但是无法表示全外连接。
对于以上语句,如果将WHERE子句中的过滤条件放到ON子句中,结果将会完全不同:
select d.dept_name, e.emp_name, e.sex, e.salary
from department d
left join employee e on (e.dept_id = d.dept_id and d.dept_name = '保卫部');
dept_name|emp_name|sex|salary|
---------|--------|---|------|
行政管理部| | | |
人力资源部| | | |
财务部 | | | |
研发部 | | | |
销售部 | | | |
保卫部 | | | |
左外连接返回了所有的部门信息,而且员工信息都为 NULL;显然,这不是我们期望的结果。我们可以通过执行计划分析一下为什么会这样,仍然以 MySQL 为例:
explain analyze
select d.dept_name, e.emp_name, e.sex, e.salary
from department d
left join employee e on (e.dept_id = d.dept_id and d.dept_name = '保卫部');
-> Nested loop left join (cost=7.60 rows=30) (actual time=0.098..0.278 rows=6 loops=1)
-> Table scan on d (cost=0.85 rows=6) (actual time=0.052..0.057 rows=6 loops=1)
-> Filter: (d.dept_name = '保卫部') (cost=0.71 rows=5) (actual time=0.035..0.035 rows=0 loops=6)
-> Index lookup on e using idx_emp_dept (dept_id=d.dept_id) (cost=0.71 rows=5) (actual time=0.020..0.032 rows=4 loops=6)
查询计划显示使用 Nested loop left join 方式执行连接操作;对于 department 使用全表扫描的方式返回 6 行记录;对于 employee 表采用索引(idx_emp_dept)查找,同时使用“d.dept_name = ‘保卫部’”作为过滤条件,循环 6 次返回了 0 行记录;最终返回了上面的结果。
作为对比,我们可以看看将过滤条件放到WHERE子句时的执行计划:
explain analyze
select d.dept_name, e.emp_name, e.sex, e.salary
from department d
left join employee e on (e.dept_id = d.dept_id)
where d.dept_name = '保卫部';
-> Nested loop left join (cost=1.98 rows=5) (actual time=0.074..0.078 rows=1 loops=1)
-> Filter: (d.dept_name = '保卫部') (cost=0.85 rows=1) (actual time=0.049..0.053 rows=1 loops=1)
-> Table scan on d (cost=0.85 rows=6) (actual time=0.039..0.047 rows=6 loops=1)
-> Index lookup on e using idx_emp_dept (dept_id=d.dept_id) (cost=1.12 rows=5) (actual time=0.021..0.021 rows=0 loops=1)
查询计划显示使用 Nested loop left join 方式执行连接操作;对于 department 通过扫描返回 1 行记录(d.dept_name = ‘保卫部’);对于 employee 表采用索引(idx_emp_dept)查找,同时使用 dept_id=d.dept_id 作为过滤条件,循环 1 次返回了 0 行记录。
我们再看一个外连接的示例:
select d.dept_name, e.emp_name, e.sex, e.salary
from department d
left join employee e on (e.dept_id = d.dept_id and e.emp_name = '赵云');
dept_name |emp_name|sex|salary |
----------|--------|---|--------|
行政管理部| | | |
人力资源部| | | |
财务部 | | | |
研发部 |赵云 |男 |15000.00|
销售部 | | | |
保卫部 | | | |
select d.dept_name, e.emp_name, e.sex, e.salary
from department d
left join employee e on (e.dept_id = d.dept_id)
where e.emp_name = '赵云';
dept_name|emp_name|sex|salary |
---------|--------|---|--------|
研发部 |赵云 |男 |15000.00|
第一个查询语句返回了所有的部门信息,以及部门中名叫“赵云”的员工;第二个查询实际上等价于内连接查询。
一般来说,对于左外连接查询,左表的过滤应该使用WHERE子句,右表的过滤应该使用ON子句;右外连接查询正好相反;全外连接的过滤条件使用ON子句。
- 上一篇:微软:IE11可选择关闭“问题大户”SSL3.0
- 下一篇:SSL(安全套接字层)
相关推荐
- 一个基于.Net Core遵循Clean Architecture原则开源架构
-
今天给大家推荐一个遵循CleanArchitecture原则开源架构。项目简介这是基于Asp.netCore6开发的,遵循CleanArchitecture原则,可以高效、快速地构建基于Ra...
- AI写代码翻车无数次,我发现只要提前做好这3步,bug立减80%
-
写十万行全是bug之后终于找到方法了开发"提示词管理助手"新版本那会儿,我差点被bug整崩溃。刚开始两周,全靠AI改代码架构,结果十万行程序漏洞百出。本来以为AI说没问题就稳了,结果...
- OneCode低代码平台的事件驱动设计:架构解析与实践
-
引言:低代码平台的事件驱动范式在现代软件开发中,事件驱动架构(EDA)已成为构建灵活、松耦合系统的核心范式。OneCode低代码平台通过创新性的注解驱动设计,将事件驱动理念深度融入平台架构,实现了业务...
- 国内大厂AI插件评测:根据UI图生成Vue前端代码
-
在IDEA中安装大厂的AI插件,打开ruoyi增强项目:yudao-ui-admin-vue31.CodeBuddy插件登录腾讯的CodeBuddy后,大模型选择deepseek-v3,输入提示语:...
- AI+低代码技术揭秘(二):核心架构
-
本文档介绍了为VTJ低代码平台提供支持的基本架构组件,包括Engine编排层、Provider服务系统、数据模型和代码生成管道。有关UI组件库和widget系统的信息,请参阅UI...
- GitDiagram用AI把代码库变成可视化架构图
-
这是一个名为gitdiagram的开源工具,可将GitHub仓库实时转换为交互式架构图,帮助开发者快速理解代码结构。核心功能一键可视化:替换GitHubURL中的"hub...
- 30天自制操作系统:第六天:代码架构整理与中断处理
-
1.拆开bootpack.c文件。根据设计模式将对应的功能封装成独立的文件。2.初始化pic:pic(可编程中断控制器):在设计上,cpu单独只能处理一个中断。而pic是将8个中断信号集合成一个中断...
- AI写代码越帮越忙?2025年研究揭露惊人真相
-
近年来,AI工具如雨后春笋般涌现,许多人开始幻想程序员的未来就是“对着AI说几句话”,就能轻松写出完美的代码。然而,2025年的一项最新研究却颠覆了这一期待,揭示了一个令人意外的结果。研究邀请了16位...
- 一键理解开源项目:两个自动生成GitHub代码架构图与说明书工具
-
一、GitDiagram可以一键生成github代码仓库的架构图如果想要可视化github开源项目:https://github.com/luler/reflex_ai_fast,也可以直接把域名替换...
- 5分钟掌握 c# 网络通讯架构及代码示例
-
以下是C#网络通讯架构的核心要点及代码示例,按协议类型分类整理:一、TCP协议(可靠连接)1.同步通信//服务器端usingSystem.Net.Sockets;usingTcpListene...
- 从复杂到优雅:用建造者和责任链重塑代码架构
-
引用设计模式是软件开发中的重要工具,它为解决常见问题提供了标准化的解决方案,提高了代码的可维护性和可扩展性,提升了开发效率,促进了团队协作,提高了软件质量,并帮助开发者更好地适应需求变化。通过学习和应...
- 低代码开发当道,我还需要学习LangChain这些框架吗?| IT杂谈
-
专注LLM深度应用,关注我不迷路前两天有位兄弟问了个问题:当然我很能理解这位朋友的担忧:期望效率最大化,时间用在刀刃上,“不要重新发明轮子”嘛。铺天盖地的AI信息轰炸与概念炒作,很容易让人浮躁与迷茫。...
- 框架设计并不是简单粗暴地写代码,而是要先弄清逻辑
-
3.框架设计3.框架设计本节我们要开发一个UI框架,底层以白鹭引擎为例。框架设计的第一步并不是直接撸代码,而是先想清楚设计思想,抽象。一个一个的UI窗口是独立的吗?不是的,...
- 大佬用 Avalonia 框架开发的 C# 代码 IDE
-
AvalonStudioAvalonStudio是一个开源的跨平台的开发编辑器(IDE),AvalonStudio的目标是成为一个功能齐全,并且可以让开发者快速使用的IDE,提高开发的生产力。A...
- 轻量级框架Lagent 仅需20行代码即可构建自己的智能代理
-
站长之家(ChinaZ.com)8月30日消息:Lagent是一个专注于基于LLM模型的代理开发的轻量级框架。它的设计旨在简化和提高这种模型下代理的开发效率。LLM模型是一种强大的工具,可以...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- 框架图 (58)
- flask框架 (53)
- quartz框架 (51)
- abp框架 (47)
- springmvc框架 (49)
- 分布式事务框架 (65)
- scrapy框架 (56)
- shiro框架 (61)
- 定时任务框架 (56)
- java日志框架 (61)
- mfc框架 (52)
- abb框架断路器 (48)
- beego框架 (52)
- java框架spring (58)
- grpc框架 (65)
- tornado框架 (48)
- 前端框架bootstrap (54)
- orm框架有哪些 (51)
- 知识框架图 (52)
- ppt框架 (55)
- 框架图模板 (59)
- 内联框架 (52)
- cad怎么画框架 (58)
- ssm框架实现登录注册 (49)
- oracle字符串长度 (48)