关联条件优化
案例1-关联条件的顺序优化
优化原因
当前版本的GNode中，LEFT JOIN的ON条件中的右表单表条件会在JOIN
之后执行，尤其当LEFT JOIN的右表是大表时，会导致参与JOIN的数据量
过大，增加JOIN耗时。
SQL特征
LEFT JOIN语句
ON条件中包含右表的单表条件
优化场景
LEFT JOIN的右表是大表
ON条件中，右表的单表条件过滤后的数据量占右表总数据量比较少（约10%
左右）。
注：因为本优化改写是把右表改写为子查询，需要考虑子查询额外的物化消
耗，因此不是所有此类SQL改写都能提升性能，尤其是当查询的投影列中出
现大量右表列时。
优化效果
通过改写，把右表单表过滤放在一个独立的子查询中，保证右表的过滤在
JOIN前执行，达到优化查询性能的目的。
示例语句：
SELECT x1.id2, x2.id2, x2.id3 FROM x1 LEFT JOIN x2 on x1.id2 = x2.id2 AND
x2.id3 = 301;
改写后语句
SELECT x1.id2, x2.id2, x2.id3 FROM x1 LEFT JOIN (SELECT x2.id2, x2.id3
FROM x2 WHERE x2.id3 = 301)
案例2-关联条件带有子查询的优化
优化原因
GNode中，LEFT JOIN的ON条件中的相关子查询无法按优化方式执行，需
要按逐行代入方式执行，这导致相关子查询的执行性能极低。
SQL特征
LEFT JOIN语句
ON条件中包含右表的单表条件，且这个单表条件是一个相关子查询
Trace信息
相关子查询无法按优化方式执行时，GNode的trace中会有如下信息
can't optimize this subselect because OUTER JOIN or "outer select's table is used
in having" or ... !
示例语句
SELECT x1.id2, x2.id2, x2.id3 FROM x1 LEFT JOIN x2 on x1.id2 = x2.id2 AND
EXISTS (SELECT 1 FROM x3 WHERE x3.id3 = x2.id3);
改写后语句
SELECT x1.id2, x.id2, x.id3 FROM x1 LEFT JOIN (SELECT id2, id3 FROM x2
WHERE EXISTS (SELECT 1 FROM x3 WHERE x3.id3 = x2.id3)) x ON x1.id2 =
x.id2;
通过新增关联条件字段,提高性能
当SQL语句中用到表内关联的计算时候，尤其是表的数据量超千万级别的时
候，可以尝试将关联计算创建为一个字段，通过新字段结果进行直接判断。
示例：
select
…
…
from rep.statcmain a ,rep.statcitemkind b;
where 表关联条件
and a.statdate <= a.endstatdate
and ..
表rep.statcmain 数据量为81864314，当表内关联计算比较a.statdate 与
a.endstatdate的大小时，耗时长，修改为如下两步进行优化，
首先在rep.statcmain上创建数值型字段 statdate_endstatdate。
令statdate_endstatdate= a.statdate- a.endstatdate。
update rep.statcmain set statdate_endstatdate = cast(statdate as date) -
cast(endstatdate as date);
表关联的时候通过statdate_endstatdate字段过滤数据。
select
…
…
from rep.statcmain a ,rep.statcitemkind b,
where 表关联条件
and statdate_endstatdate <= 0
and ..
性能对比：优化前执行1小时50分钟，优化后执行45分钟
