百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术文章 > 正文

多表关联查询过滤条件写在on与where后的区别

ccwgpt 2024-12-12 11:11 41 浏览 0 评论

SQL优化过程中,发现开发人员在写多表关联查询的时候,对于谓词过滤条件的写法很随意,写在on后面与where后面的情况均有,这可能会导致没有理解清楚其真正的含义而无法得到期望的结果。

多表关联连接方式有inner join、left join、right join、full join四种,下面通过实验来说明不同连接方式谓词放在on与where后的效果与影响。

初始化测试数据

create table t1(id number(10),name varchar2(30),status varchar2(2));
create table t2(id number(10),mobile varchar2(30));
insert into t1 values(1,'a','1');
insert into t1 values(2,'b','1');
insert into t1 values(3,'c','1');
insert into t1 values(4,'d','1');
insert into t1 values(5,'e','1');
insert into t1 values(6,'f','0');
insert into t1 values(7,'g','0');
insert into t1 values(8,'h','0');
insert into t1 values(9,'i','0');
insert into t1 values(10,'j','0');
insert into t2 values(1,'12345');
insert into t2 values(2,'23456');
insert into t2 values(3,'34567');
insert into t2 values(6,'67890');
insert into t2 values(7,'78901');

1.Inner join

SQL>select * from t1 inner join t2 on t1.id=t2.id and t1.status=‘1’;

   ID NAME                          ST         ID MOBILE
     1 a                            1           1 12345
     2 b                            1           2 23456
     3 c                            1           3 34567

SQL> select * from t1 inner join t2 on t1.id=t2.id where t1.status=‘1’;

   ID NAME                         ST         ID MOBILE
     1 a                            1           1 12345     
     2 b                            1           2 23456
     3 c                            1           3 34567

我们发现谓词t1.status=’1’放在on后与where后结果一样,它们的执行计划相同,说明CBO对这两种情况做了相同处理。
执行计划如下图所示:

Inner join时谓词不管放在哪个位置,CBO都先对t1表过滤,再与t2表关联。

2.left join

(1)左右表谓词过滤都放在on后面:
SQL> select * from t1 left join t2 on t1.id=t2.id and t1.status=‘1’ and t2.id<3;

  ID NAME                           ST         ID MOBILE
      1 a                            1           1 12345
      2 b                            1           2 23456
      3 c                            1    
      8 h                            0    
      5 e                            1    
      9 i                            0   
     10 j                            0    
      7 g                            0    
      6 f                            0    
      4 d                            1

执行计划如下:

从执行计划可以看出,t1.status=’1’放在on后面,t1表并没有对谓词status进行过滤,结果集显示t1的全表数据。这是由left join的特性决定的,左表会显示全部数据。t2.id<3是先对t2表进行过滤再进行连接,而t1.status=’1’是作为连接条件存在,对连接时产生的笛卡尔积数据做连接过滤。
(2)左右表谓词过滤都放在where后面:
SQL>select * from t1 left join t2 on t1.id=t2.id where t1.status=‘1’ and t2.id<3;

   ID NAME                           ST         ID MOBILE
       1 a                            1           1 12345
       2 b                            1           2 23456

从执行计划可以看出,谓词放在where后面,是先对表进行过滤,然后再对过滤后的数据进行连接。而且我们发现t1表上自动加上了id<3的过滤条件,这是因为有t1.id=t2.id等值连接,如果t1表上id列有索引,性能就能看出差别来了。注意连接方式变成了hash join,这是因为右表的谓词过滤条件写在where后面,CBO会把左连接等价为内连接。

(3)右表的谓词写在on后面,左表的谓词写在where后面:
SQL>select * from t1 left join t2 on t1.id=t2.id and t2.id<3
where t1.status=‘1’; 2

  ID NAME                          ST         ID MOBILE
      1 a                            1           1 12345
      2 b                            1           2 23456
      5 e                            1
      4 d                            1
      3 c                            1

当把对右表的过滤写在on后面,先对两表进行过滤,再进行left join,显示结果集与写在where后面是不同的,连接方式还是左外连接,显示t1过滤后的全部数据。
(4)右表的谓词写在where后面,左表的谓词写在on后面:
SQL> select * from t1 left join t2 on t1.id=t2.id and t1.status=‘1’ where t2.id<7;

   ID NAME                       ST         ID MOBILE
     1 a                            1           1 12345
     2 b                            1           2 23456
     3 c                            1           3 34567

从执行计划看这种情况左连接转换为内连接,左表的谓词条件写在哪个位置都一样。而且因为t2表过滤后数据比t1表少,CBO把t2表当成了驱动表。
接下来我们再看一个语句:
SQL> select * from t1 left join t2 on t1.id=t2.id and t1.status=‘1’
where t1.status=‘0’ ;

  ID NAME                        ST         ID MOBILE
    8 h                            0
    6 f                            0
    9 i                            0
  10 j                            0
   7 g                            0

从执行计划看出,虽然t2表返回0行,步骤3上的filter条件肯定不成立,但有逻辑读消耗,所以推断它依然进行了全表扫描,所以这种语句对t2表的扫描是对资源的一种浪费,没有意义。或许你会觉得谁会这么无聊写这种SQL,但是在开发过程中,SQL语句经常是各种过滤条件组合经过拼接而成,因为返回结果是对的,他们意识不到会出现这种问题,在此说明此种情况主要是想说明一件事:不要总想着用一个语句来解决所有的功能需求,适当的拆分对性能的提升是很有必要的。

3.right join

右连接与左连接是相似的,只不过是右表显示全部数据,写在on后面谓词过滤对右表不起作用,在此不再举例说明。

4.full join

全连接在应用中似乎很少碰到,但是存在即合理,只是自己没有遇到而已。
(1)两个表的谓词都放在on的后面:

这种情况不会先对两个表过滤,而是作为连接条件过滤,符合连接就匹配上,不符合的就把左右两表的数据都显示出来,另一表的字段以空显示。
(2)两个表的谓词都放在where后面:

这种情况CBO将其转换为内连接,先过滤再关联。
(3)左表谓词放在on后面,右表放在where后面:

这种情况转换为右外连接,但是也是先对两表过滤后再关联。
(4)左表谓词放在where后面,右表放在on后面:

这种情况转换为左外连接,也是先对两表过滤后再关联。

总结

1.对于内连接inner join,两个表的谓词条件放在on与where后面相同。
2.对于left join:
左表谓词放在on后不会对左表数据进行过滤,依然显示左表全部数据,放在where后面才会对左表进行过滤
右表谓词不管放在on后还是where后都会对右表先过滤再连接,但是放在where后left join会转换为inner join。
3.对于外连接,谓词条件放的位置不同,结果集也不同,可以根据自己的需求斟酌使用。

墨天轮原文链接:https://www.modb.pro/db/101411(复制链接至浏览器或点击多表关联查询过滤条件写在on与where后的区别 - 墨天轮查看)

关于作者

于志君,云和恩墨技术顾问,Oracle 12c OCM。拥有OCM、OBCA证书,曾在某大型国企做过多年数据库运维工作,现驻场于某银行,专门从事SQL性能优化工作,热衷于运维故障处理、备份恢复、升级迁移、性能优化的学习与分享。

相关推荐

一个基于.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模型是一种强大的工具,可以...

取消回复欢迎 发表评论: