大表全表扫描引起OOM异常处理

集群环境：

集群版本V8，操作系统CentOS7.6

问题描述:

某GBase 8a集群连续几天在个别节点出现gbased-oom异常，通过SQL日志，定位可疑SQL如下：

insert into tmp ds_02288_s2_001_bak select * from tmp_ds_02288_32_001 where right(trim(imsisdn), 1) = '0'

问题分析：

问题出现时段为上午时段业务高峰期，闲时重复执行SQL正常。

nmon日志显示7点30左右，有一个IO异常峰值，超过10000/sec，与上述语句运行时段吻合。

虽然系统并发任务数不高，但大部分为亿级以上大表的复杂关联聚合运算。

SQL中的源表tmp_ds_02288_32_001记录数较大，超过10亿。

初步判断，问题原因与扫描条件right(trim(msisdn)，1)='0'中的字段使用了函数导致全表扫描，使用了较大IO及内存资源有关，从而导致oom异常。

改写测试，应用将right(trim(msisdn)，1)='0'改写为trim(msisdn) like '%0' 或msisdn like '%0'（这个性能最好），没有再出现异常。

经验总结，扫描条件对字段尽量规避函数调用，尤其是对大表，可以利用集群的智能索引（规避全表扫描），从而降低内存及IO资源使用率，提升SQL性能同时降低oom异常几率。