异大
问题现象
两表like 条件关联使用limit 和limit offset 性能差异大,如下示例,该SQL 执行
时跑了几万秒没有结果,但把最后的limit 0,500 换成limit 500,20 秒左右就可
GBase 8a MPP Cluster 最佳实践
5 FAQ
文档版本(2022-02-11)
南大通用数据技术股份有限公司
94
以执行完毕。
SELECT a.*
,b.addr_full_name
,b.gridcode
FROM gd_eda.temp_wyj_obd_01 a
,gd_lx.address_grid b
WHERE b.addr_full_name LIKE a.address || '%'
AND a.address IS NOT NULL
AND b.gridcode IS NOT NULL limit 0,500
解决方法
Limit 0,500 时,在默认set _t_gcluster_limit_optimize=1;的情况下,执行器会
先去各个节点评估本节点结果集行数,该语句2 表关联条件为b.addr_full_na
me like a.address||'%',左表(小表,数据量为140 多万)拉复制表后,与右
表的分片按nest-loop 方式join,2 表数据量都很大,join 执行的时间长,导致
长时间评估不完;
limit 500 时,不按照上述优化执行,直接下发到第一个节点执行,虽然也是
nest-loop join,但是当结果集行数到500 时就退出了,对外表现性能更好;
性能差异的根本原因是在sql 的join 上面,建议请用户核查下sql 的逻辑是否
有问题;或session 级设置上述参数值为0。
改造业务逻辑或者执行该sql 时设置set _t_gcluster_limit_optimize=0。