hive join on 条件 与 where 条件区别

背景

最近项目组上,来了几个实习生,对 Hive sql 的 join 的使用不是很熟悉,几个人写出来的sql 看上去感觉都是一样的,但结果可能会出现,扫描全表,耗时过久,造成数据有所有差异

业务场景

根据常见的场景,写了几条sql ,看 on 和 where 的作用域 ,查询 事实表 a 中的在 20200602 这天的数据,维度表 b
对于上述的这种需求 ,有可能会出现下列这几种sql

sql1

select 
	*
from a 
left join b 
  on a.id = b.id 
  and a.date=20200602;

sql2

select 
	*
from a 
left join b 
  on a.id = b.id 
  and b.date=20200602;

sql3

select 
	*
from a 
join b 
  on a.id = b.id 
  and a.date=20200602;

sql4

select 
	*
from a 
join b 
  on a.id = b.id and b.date=20200602
where a.date=20200602;

结论

sql1: 如果是left join 在on上写主表a的条件不会生效,全表扫描。

sql2: 如果是left join 在on上写副表b的条件会生效,但是语义与写到where 条件不同,写到on后,先过滤后关联,写到where后,先关联后过滤

sql3: 如果是inner join 在on上写主表a、副表b的条件都会生效

sql4: 结合 前三条 sql 的结果,建议这么写,先过滤a表数据和b表数据,后关联join

执行顺序
1.where a.date=20200602 (过滤a)
2. b.date=20200602(过滤b)
3.a.id = b.id (关联)
<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、付费专栏及课程。

余额充值