DECODE 和 CASE WHEN 在执行计划中无区别，Oracle 优化器将其归一化为同一表达式节点；二者性能、内存占用相同，嵌套 DECODE 不提升效率但损害可读性，CASE WHEN 支持更灵活的布尔逻辑。
DECODE 和 CASE WHEN 在执行计划里其实没区别
oracle 优化器对 decode 和标准 case when 的处理方式基本一致，只要逻辑等价、分支类型兼容，生成的执行计划几乎完全相同。这不是“语法糖差异”，而是 oracle 内部早已将二者归一化为同一类表达式节点。
实操建议：
- 别为了“性能”硬换
DECODE—— 它不比CASE WHEN快，也不更省内存 - 如果用到嵌套（比如
DECODE(DECODE(...))），可读性会断崖下跌，但执行效率不会提升 -
CASE WHEN支持布尔表达式（如col > 10 AND col ），<code>DECODE只能做等值判断，强行用DECODE模拟范围逻辑会导致冗余函数调用（比如套SIGN或TRUNC），反而拖慢
NULL 判断写法不当会引发隐式转换和索引失效
这是最常踩的坑：用 DECODE(col, NULL, 'X', 'Y') 或 CASE WHEN col = NULL THEN ...，前者语法合法但永远不匹配（因为 NULL = NULL 是 UNKNOWN），后者直接语法报错 ORA-00936: missing expression。
正确写法只有两种：
CASE WHEN col IS NULL THEN 'X' ELSE 'Y' END-
DECODE(col, NULL, 'X', 'Y')—— 注意：这里DECODE对NULL是特例支持，不是靠=比较，但仅限第一个参数为NULL字面量时才生效；若写成DECODE(col, my_null_var, ...)，依然不匹配
一旦误写成 CASE WHEN col = NULL，语句虽报错拦住，但若裹在动态 SQL 或视图定义里，可能漏检，上线后逻辑全错。
大量分支下，CASE WHEN 的编译开销略高但可忽略
当分支超过 20–30 个，PL/SQL 编译器解析 CASE WHEN 的时间会微增（纳秒级），而 DECODE 因语法简单，解析稍快。但这对运行时性能无任何影响——真正耗时的是分支内表达式的计算，不是结构本身。
更关键的取舍点在于维护性：
-
DECODE(a, 1,'A', 2,'B', 3,'C', ..., 'Z')—— 参数成对堆砌，改一个值要数位置，极易错位 -
CASE WHEN a = 1 THEN 'A' WHEN a = 2 THEN 'B' ... ELSE 'Z' END—— 每行逻辑自包含，加删分支不影响其余，调试时也容易单步定位 - 如果分支逻辑涉及函数调用（如
TO_CHAR(dt, 'YYYY')），放在CASE外层计算一次再传入，比在每个WHEN子句里重复算更高效
绑定变量与条件判断组合时，别让 CASE 成为执行计划“稳定器”
常见反模式：WHERE CASE WHEN :p_flag = 'Y' THEN col ELSE 1 END = CASE WHEN :p_flag = 'Y' THEN :p_val ELSE 1 END。表面看是动态过滤，实际会让优化器放弃对 col 的索引选择，固定走全表扫描。
真正高效的写法是用 OR 拆解或动态拼 SQL：
- 静态 SQL 推荐：
WHERE (:p_flag != 'Y') OR (col = :p_val)—— Oracle 11g+ 能对这种写法做谓词推导，仍可能走索引 - 若分支逻辑复杂（如不同字段、不同操作符），用
EXECUTE IMMEDIATE拼接更安全，避免执行计划被“污染” -
CASE在 SELECT 列表中用于计算字段没问题，但一旦进 WHERE 或 JOIN 条件，就要警惕它是否掩盖了真实可推导的过滤意图
最易被忽略的是：开发阶段用小数据集测试时看不出性能问题，等上生产面对千万级表，一个本该走索引的查询变成全扫，才意识到 CASE 在谓词里的“柔顺假象”有多危险。
