关联条件优化
1.案例1-关联条件的顺序优化
优化原因：当前版本的GNode中，LEFTJOIN的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 ANDx2.id3 = 301;
改写后语句
SELECT x1.id2, x2.id2, x2.id3 FROM x1 LEFT JOIN (SELECT x2.id2, x2.id3FROM x2 WHERE x2.id3 = 301) x;
2.案例2-关联条件带有子查询的优化
优化原因
GNode中，LEFTJOIN的ON条件中的相关子查询无法按优化方式执行，需要按逐行代入方式执行，这导致相关子查询的执行性能极低。
SQL特征
LEFT JOIN语句ON条件中包含右表的单表条件，且这个单表条件是一个相关子查询
Trace信息相关子查询无法按优化方式执行时，GNode 的trace中会有如下信息：can't optimize this subselect because OUTER JOIN or "outer select's table is usedin having" or ... !
示例语句
SELECT x1.id2, x2.id2, x2.id3 FROM x1 LEFT JOIN x2 on x1.id2 = x2.id2 ANDEXISTS (SELECT 1 FROM x3 WHERE x3.id3 = x2.id3);
改写后语句
SELECT x1.id2, x.id2, x.id3 FROM x1 LEFT JOIN (SELECT id2, id3 FROM x2WHERE EXISTS (SELECT 1 FROM x3 WHERE x3.id3 = x2.id3)) x ON x1.id2 =x.id2;
3.案例3-通过新增关联条件字段,提高性能
当SQL语句中用到表内关联的计算时候，尤其是表的数据量超千万级别的时候，可以尝试将关联计算创建为一个字段，通过新字段结果进行直接判断。
示例：select……from rep.statcmain a ,rep.statcitemkind b;where表关联条件and a.statdate <= a.endstatdateand ..
表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 <= 0and ..性能对比：优化前执行1小时50分钟，优化后执行45分钟。
