LEFT JOIN 需要注意的点(Presto)

最近工在Presto中用了很多关联查询操作,遇到了一些问题再这里记录一下。

LEFT JOIN的基本概念

LEFT JOIN是我们最常用的关联查询,对于之前很少直接接触复杂关联查询的兄弟,我们还是需要弄清楚一些基本概念。

  • LEFT JOIN是逻辑操作符,对于放在左边的表来说,是以其为base,如果SELECT查询的字段全都来自左边的表,那么最终的结果条数会 >= 左表条数
  • 数据库优化器是最终决定执行顺序的地方,一般的会按照你的LEFT JOIN的顺序执行,但也不保证完全是那样。

怎么执行呢?

例如:

SELECT table_1.a, table_1.b, table_1.c
FROM table_1 
    LEFT JOIN table_2
    ON table_1.uid = table_2.uid
    LEFT JOIN talbe_3
    ON table_1.uid = table_3.uid

执行顺序是:table_1和table_2先组合成一个虚拟表,然后这个虚拟表再和table_3关联。

多个LEFT JOIN连接,记录的条数是不是主表的条数?

如上面的语句,在没有WHERE语句情况下,是大于等于table_1的条数。
这是因为:

- SELECT 后面的字段均来自table_1;
- 所有的关联条件都是为了匹配table_1;

LEFT JOIN后数据量增加的问题

但是有一种情况,最终结果可能是大于table_1的情况的,那就是在table_2或者table_3中有重复的uid,并且正好符合关联条件的时候,结果表就会被撑大。

如下面的情况:

这里先考虑只有table_2的情况。
table_1中有如下数据:

uidabc
1100101102
2200201202
3300301302

如果table_2是以下形式:

uidab
11010
11010
22010
22010

如果没有去重,最终的结果就是:

abc
100101102
100101102
200201202
200201202
300301302

为了看得更清楚一些,我们改写一下SQL语句:

SELECT 
    table_1.a t1_a, table_1.b t1_b, 
    table_1.c t1_c, table_1.uid t1_uid,
    table_2.uid t2_uid, table_2.a t2_a,
    table_2.b t2_b
FROM table_1
    LEFT JOIN table_2
    ON table_1.uid = table_2.uid;
t1_at1_bt1_ct1_uidt2_uidt2_at2_b
100101102111010
100101102111010
200201202222010
200201202222010
3003013023NULLNULLNULL

我们可以清楚的看到,uid=1, uid=2被分别匹配了两次。

怎样解决?

我们可以考虑想将table_2去重。

我们可以先利用一个子查询去掉重复的记录,然后再与table_1进行联合。这里使用了Presto的语法

WITH table_2 AS (
    SELECT distinct uid, a, b 
    FROM table_2
)
SELECT 
    table_1.a t1_a, table_1.b t1_b, 
    table_1.c t1_c, table_1.uid t1_uid,
    table_2.uid t2_uid, table_2.a t2_a,
    table_2.b t2_b
FROM table_1
    LEFT JOIN table_2
    ON table_1.uid = table_2.uid;

结果为:

t1_at1_bt1_ct1_uidt2_uidt2_at2_b
100101102111010
200201202222010
3003013023NULLNULLNULL

这样就避免了被关联表中的重复记录影响最终结果。

上面的情况在处理大数据量的表时,最容易造成“Insufficient Resources”的error,导致Presto罢工。所以一定要小心。

LEFT JOIN后得到的数据许多NULL数据

如果被关联的表中没有能匹配关联条件,这会让数据库用NULL去填充结果。
如果你的查询结果是两个表字段共同决定的,要信息处理这个问题。
例如(table_1和table_2还是用上面的数据):

WITH table_2 AS (
    SELECT distinct uid, a, b 
    FROM table_2
)
SELECT 
    table_2.a a, table_2.b b, table_1.c c
FROM table_1
    LEFT JOIN table_2
    ON table_1.uid = table_2.uid;

得到的结果就是:

abc
1010102
2010202
NULLNULL302

所以,要加上if语句进行判断。

WITH table_2 AS (
    SELECT distinct uid, a, b 
    FROM table_2
)
SELECT 
    if(table_2.a IS NOT NULL, table_2.a, table_1.a) a, 
    if(table_2.b IS NOT NULL, table_2.b, table_1.b) b, 
    table_1.c c
FROM table_1
    LEFT JOIN table_2
    ON table_1.uid = table_2.uid;

得到的结果:

abc
1010102
2010202
300301302

JOIN的左边尽量放小数据量的表

这样可以提高查询效率,优化查询速度。

不要JOIN(LEFT RIGHT FULL等等)起来没完

要知道,每次JOIN关联,数据库都会先将两边的数据进行全量组合(也就是笛卡尔积的形式),然后再进行条件筛选,会造成服务器资源紧张。
所以,我们需要将许多的JOIN用with语句分割成多个子查询,然后再一步一步关联。

但是也要注意,在做ETL清洗时,一般需要将一个表的全量字段经过清洗步骤,然后插入到另一个目标表中。这时,子查询很多的情况,也会使得服务器的内存紧张,必要的时候我们可以采用临时表的方案,用临时表存储一些中间结果,最后再综合中间结果完成整个操作。

    原文作者:SQL
    原文地址: https://segmentfault.com/a/1190000013121493
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞