SQL中条件放在on后与where后的区别

SQL中on条件与where条件的区别

 

       数据库在通过连接两张或多张表来返回记录时,都会生成一张中间的临时表,然后再将这张临时表返回给用户。

      在使用left jion时,on和where条件的区别如下:

1、 on条件是在生成临时表时使用的条件,它不管on中的条件是否为真,都会返回左边表中的记录。

2、where条件是在临时表生成好后,再对临时表进行过滤的条件。这时已经没有left join的含义(必须返回左边表的记录)了,条件不为真的就全部过滤掉。

       假设有两张表:

表1:tab2

id
size
1
10
2
20
3
30

表2:tab2

size
name
 
10
AAA
20
BBB
20
CCC

两条SQL: 1、select * form tab1 left join tab2 on (tab1.size = tab2.size) where tab2.name=’AAA’

2、select * form tab1 left join tab2 on (tab1.size = tab2.size and tab2.name=’AAA’)

第一条SQL的过程:

1、中间表 on条件: tab1.size = tab2.size
tab1.idtab1.sizetab2.sizetab2.name
1
10
10
AAA
2
20
20
BBB
2
20
20
CCC
3
30
(null)
(null)
|
|

2、再对中间表过滤 where 条件: tab2.name=’AAA’

tab1.idtab1.sizetab2.sizetab2.name
1
10
10
AAA
  

 

第二条SQL的过程:

1、中间表 on条件: tab1.size = tab2.size and tab2.name=’AAA’ (条件不为真也会返回左表中的记录)
tab1.idtab1.sizetab2.sizetab2.name
1
10
10
AAA
2
20
(null)
(null)
3
30
(null)
(null)

     其实以上结果的关键原因就是left join,right join,full join的特殊性,不管on上的条件是否为真都会返回left或right表中的记录,full则具有left和right的特性的并集。 而inner jion没这个特殊性,则条件放在on中和where中,返回的结果集是相同的。

 

可以这样理解:on是在生成连接表的起作用的,where是生成连接表之后对连接表再进行过滤。

当使用left join时,无论on的条件是否满足,都会返回左表的所有记录,对于满足的条件的记录,两个表对应的记录会连接起来,对于不满足条件的记录,那右表字段全部是null

当使用right join时,类似,只不过是全部返回右表的所有记录

当使用inner join时,功能与where完全相同。

 

经过亲测后,更加深了对on和where的理解,得出以下结论:

0. on后的条件如果有过滤主表的条件,则结果对于不符合该条件的主表数据也会原条数保留,只是不匹配右表数据而已。对于on后面对右表的过滤条件,连接时会用该条件直接过滤右表数据后再和左边进行左连接。总之,对于不满足on后面的所有条件的数据,左表会在结果数据中原条数保留数据,只是不匹配右表数据而已。不满足条件的右表数据各字段会直接以NULL连接主表。

1.ON后对左表的筛选条件对于结果行数会被忽略,但会影响结果中的匹配右表数据,因为只有符合左表条件的数据才会去和符合条件的右表数据进行匹配,不符合条件的左表数据会保留在最后结果中,但匹配的右表数据都是NULL.因此,对于需要过滤左表数据的话,需要把过滤条件放到where后面。

2.ON后的左表条件(单独对左表进行的筛选条件)对于结果行数无影响,还是会返回所有左表的数据,但和右表匹配数据时,系统只会拿左表符合条件(ON后的对左表过滤条件)的数据去和右表符合条件(ON后的对右表过滤条件)的数据进行匹配抓取数据,而不符合条件的左表数据还是会出现在结果列表中,只是对应的右表数据都是NULL。

3.ON后的右表条件(单独对右表进行的筛选条件)会先对右表进行数据筛选后再和左表做连接查询,对结果行数有影响(当左表对右表是一对多时),但不会影响左表的显示行数,然后拿符合条件的右表数据去和符合条件的左表数据进行匹配。

4.Where还是对连接后的数据进行过滤筛选,这个无异议。

5.匹配数据时无论左右表,都是拿符合ON后的过滤条件去做数据匹配,不符合的会保留左表数据,用NULL填充右表数据。

综上得出,ON后面对于左表的过滤条件,在最后结果行数中会被忽略,并不会先去过滤左表数据再连接查询,但是ON后的右表条件会先过滤右表数据再连接左表进行查询。

连接查询时,都是用符合ON后的左右表的过滤条件的数据进行连接查询,只有符合左右表过滤条件的数据才能正确匹配,剩下的左表数据会正常出现在结果集中,但匹配的右表数据是NULL。因此对于左表的过滤条件切记要放到Where后,对于右表的过滤条件要看情况了。如果需要先过滤右表数据就把条件放到ON后面即可。

on、where、having的区别
 
on、where、having这三个都可以加条件的子句中,on是最先执行,where次之,having最后。有时候如果这先后顺序不影响中间结果的话,那最终结果是相同的。但因为on是先把不符合条件的记录过滤后才进行统计,它就可以减少中间运算要处理的数据,按理说应该速度是最快的。          根据上面的分析,可以知道where也应该比having快点的,因为它过滤数据后才进行sum,所以having是最慢的。但也不是说having没用,因为有时在步骤3还没出来都不知道那个记录才符合要求时,就要用having了。          在两个表联接时才用on的,所以在一个表的时候,就剩下where跟having比较了。在这单表查询统计的情况下,如果要过滤的条件没有涉及到要计算字段,那它们的结果是一样的,只是where可以使用rushmore技术,而having就不能,在速度上后者要慢。          如果要涉及到计算的字段,就表示在没计算之前,这个字段的值是不确定的,根据上篇写的工作流程,where的作用时间是在计算之前就完成的,而having就是在计算后才起作用的,所以在这种情况下,两者的结果会不同。          在多表联接查询时,on比where更早起作用。系统首先根据各个表之间的联接条件,把多个表合成一个临时表后,再由where进行过滤,然后再计算,计算完后再由having进行过滤。由此可见,要想过滤条件起到正确的作用,首先要明白这个条件应该在什么时候起作用,然后再决定放在那里

转载于:https://www.cnblogs.com/itjeff/p/3524236.html

<think>嗯,用户问的是Hive SQL中左连接(LEFT JOIN)的ON条件WHERE条件区别。我得先回忆一下Hive的处理逻辑。根据之前的引用资料,记得左连接时,ON条件不会过滤左表的数据,无论ON里的条件是否满足,左表的记录都会保留。而WHERE条件是在连接之后应用的,所以会过滤掉不符合条件的行,包括左表中那些在右表没有匹配到的行,这可能导致LEFT JOIN变成类似INNER JOIN的效果。 首先,要明确左连接的基本特性:保留左表所有记录,右表没有匹配的则填充NULL。如果过滤条件放在ON里,比如右表的某个字段,这时候ON里的条件会影响右表的记录是否匹配,但左表的记录依然会被保留。例如,在引用[1]中提到,如果将右表的过滤条件放在WHERE里,会导致LEFT JOIN变成INNER JOIN,因为WHERE会在连接后过滤掉右表为NULL的行,这样左表原本保留的行可能就被排除了。 然后,引用[2]和[4]都强调了ONWHERE的执行顺序不同。ON条件是在连接过程中应用的,而WHERE是在连接之后。对于左连接来说,ON里的条件只会影响右表是否匹配,不会影响左表的数据保留。而WHERE则会对整个结果集进行过滤,包括左表的记录。如果左表的某个条件放在WHERE里,那么那些不符合条件的左表记录也会被过滤掉,这时候LEFT JOIN的效果可能就不如预期了。 还要考虑到NULL值的问题,如引用[3]提到的,比较运算可能返回NULL,这会影响条件判断。在ON条件中,如果右表的某个字段为NULL,可能会导致条件不满足,但左表的记录依然存在。而WHERE中的条件如果涉及右表字段,会排除那些右表为NULL的行,从而改变结果。 用户可能需要具体的例子来理解,所以最好给出两个对比的示例,比如在ON里过滤右表和在WHERE里过滤右表的不同结果。同时,还要说明如果对左表使用WHERE条件,会直接过滤左表的数据,这在LEFT JOIN中可能不适用,除非确实需要过滤左表。 总结起来,关键点在于执行顺序和过滤的对象:ON影响右表的匹配,WHERE影响整个结果集。需要确保用户明白这两种条件放置位置的不同影响,避免误用导致查询结果不符合预期。</think>### Hive SQL左连接(LEFT JOIN)中ON条件WHERE条件区别 #### 一、核心区别 在Hive SQL中,`ON`条件`WHERE`条件的执行顺序和语义逻辑有本质差异: 1. **`ON`条件** - 作用于**连接过程**,仅影响**右表记录的匹配逻辑** - 即使条件不满足,**左表记录仍会被保留**(右表字段填充`NULL`) - 例如: ```sql SELECT * FROM a LEFT JOIN b ON a.id = b.id AND b.dt = '2023-01-01' -- 右表过滤条件 ``` 此时右表`b`未匹配的记录会显示为`NULL`,但左表`a`所有记录仍保留[^1][^2][^4]。 2. **`WHERE`条件** - 作用于**连接完成后的结果集**,对所有字段进行过滤 - 会**直接过滤掉不符合条件的记录**(包括左表记录) - 例如: ```sql SELECT * FROM a LEFT JOIN b ON a.id = b.id WHERE b.dt = '2023-01-01' -- 全局过滤条件 ``` 此时左表中未匹配到`b.dt='2023-01-01'`的记录会被过滤,相当于`INNER JOIN`。 #### 二、执行顺序对比 $$ \text{执行顺序:ON条件 → 连接操作 → WHERE条件} $$ - **优先级**:`ON`条件优先级高于`WHERE`条件 - **数据保留**:`WHERE`条件可能导致左表数据丢失,`ON`条件仅影响右表匹配结果[^2] #### 三、典型场景分析 | 场景 | 条件位置 | 左表数据保留 | 右表数据匹配 | 等效操作 | |------|----------|--------------|--------------|----------| | 过滤右表 | `ON` | ✔️ | 仅匹配符合条件的记录 | 标准LEFT JOIN | | 过滤右表 | `WHERE` | ❌ | 过滤掉所有未匹配记录 | INNER JOIN | | 过滤左表 | `ON` | ✔️ | 不影响左表过滤 | 无效操作 | | 过滤左表 | `WHERE` | ❌ | 直接过滤左表记录 | 普通WHERE过滤 | #### 四、NULL值处理 当比较运算涉及`NULL`值时(例如`1 < NULL`),结果为`NULL`,在条件判断中会被视为`FALSE`[^3]。 例如:`WHERE b.col > 10`会排除`b.col IS NULL`的记录。 #### 五、实验验证 ```sql -- 测试数据 CREATE TABLE a (id INT, value STRING); INSERT INTO a VALUES (1,'A'), (2,'B'); CREATE TABLE b (id INT, status STRING); INSERT INTO b VALUES (1,'C'), (2,'D'); -- 场景1:ON条件过滤右表 SELECT * FROM a LEFT JOIN b ON a.id = b.id AND b.status <> 'C'; -- 结果:保留所有左表记录,右表id=1的记录被过滤 -- 场景2:WHERE条件过滤右表 SELECT * FROM a LEFT JOIN b ON a.id = b.id WHERE b.status <> 'C'; -- 结果:仅保留id=2的记录(左表id=1的记录被过滤) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值