YashanDB|decode 子查询被多次执行?性能骤降的真相找到了!

在某些使用场景中，客户反馈 YashanDB 执行一条 decode 函数嵌套子查询的 SQL 时，耗时超过 6 分钟仍未出结果。经过深入分析，我们发现这是由 decode 执行机制上的一个隐性逻辑错误引起的。

一、问题现象

执行简单的 select decode(...) 语句，返回时间异常缓慢;

即便子查询逻辑非常轻量，整条语句也会持续卡顿;

多次尝试后发现性能极其不稳定。

二、问题风险与影响

SQL 响应时间过长，直接影响业务流程;

对数据库资源消耗大，可能引发后续慢 SQL 堆积;

在大数据量下尤为严重，极易放大问题影响范围。

三、影响版本说明

影响版本：YashanDB 所有 22.2 系列版本;

正常版本：23.2 起已修复该问题。

四、问题根本原因分析

根本原因在于：

在 decode 函数的执行中，即便某个分支不满足条件，其中的子查询依然会被执行;

本应只在分支条件命中时才执行的子查询，结果每一条记录都触发一次，导致无意义的重复计算。

五、典型案例还原

我们构造了以下实验场景：

表结构设计

表 a 设置了 pctfree=99.每个数据块只存储一条记录;

表内有约 1000 条数据，即产生 1000 个数据块。

SQL 示例

select decode(rn, 1. (select tname from a where tid = b.rn), 'abcd')
from (select rownum rn from dual connect by rownum < 5) b;

正常情况预期

decode 只在 rn=1 时执行子查询;

实际上只访问一次表 a，产生约 1000 个一致读。

异常情况（22.2版本）

每一条记录都触发一次对 a 的子查询;

最终产生约 4000 次一致读，性能骤降。

六、解决方法与规避建议

当前版本中可以通过以下方式规避问题：

替代写法：使用case when结构代替decode

将原本的 decode 重写为：

select case when rn = 1 then (select tname from a where tid = b.rn) else 'abcd' end
from (select rownum rn from dual connect by rownum < 5) b;

实测表明：改为 case when 后，数据库会按需执行子查询，仅在匹配分支时执行，避免不必要的重复计算。

七、分析技巧推荐

使用如下方式辅助判断 SQL 性能异常是否由一致读放大引起：

开启 statistics_level=all;

使用 autotrace 查看一致读数量，判断是否远超预期。

八、小结建议

在 YashanDB 22.2 版本中使用 decode 时，避免在其分支中嵌套子查询;

推荐统一将复杂条件逻辑改写为 case when，更加可控;

如遇 SQL 性能异常，可优先排查一致读次数，辅助定位问题源头。