DECODE 并不比 CASE WHEN 更快或更省内存，二者执行计划相同；Oracle 10g+优化器会将语义等价的 DECODE 和 CASE WHEN 归一化为同一表达式节点。
别为性能硬换 decode —— 它不比 case when 快，也不更省内存，但写错 null 判断会直接让逻辑失效。
DECODE 和 CASE WHEN 的执行计划其实一样
Oracle 优化器在 10g 及之后版本中，会把语义等价的 DECODE 和 CASE WHEN 归一化为同一类表达式节点。你用 EXPLAIN PLAN 看到的执行计划一致，不是巧合，是优化器主动做了等价转换。
这意味着：
- 分支数少（
- 所谓“DECODE 更快 15%”的测试结果，往往来自未控制变量的场景：比如测试用了隐式转换、没绑定变量、或混入了不同复杂度的子查询
- 真正影响性能的是分支内表达式的计算（如
TO_DATE(col)）、索引是否可用、以及是否触发全表扫描，不是外层用DECODE还是CASE
CASE WHEN 支持而 DECODE 不支持的语法必须用前者
一旦出现以下任一情况，DECODE 就无法替代 CASE WHEN，强行硬套只会让代码脆弱且难调试：
-
CASE WHEN salary >= 10000 THEN '高' END——DECODE不支持>=、BETWEEN、LIKE等非等值判断 -
CASE WHEN SUBSTR(name, 1, 2) = 'AB' THEN '匹配' END——DECODE的 search 参数只能是字面量或列名，不能是函数结果 -
CASE WHEN dept_id = 10 AND job = 'MANAGER' THEN '高管' END——DECODE无法联合多列做条件 -
WHERE CASE WHEN :p_flag = 'Y' THEN col ELSE 1 END = :p_val—— 在WHERE中动态控制谓词时，CASE结构清晰，DECODE易写错且难推导索引
NULL 判断写法错误是上线后最危险的坑
CASE WHEN col = NULL THEN ... 会直接报错 ORA-00936: missing expression，反而是种保护；但 DECODE(col, NULL, 'X', 'Y') 表面合法，实际永远不匹配（除非第一个参数就是字面量 NULL）。
更隐蔽的问题是：
- 写成
DECODE(col, NVL(my_null_var, NULL), 'X', 'Y')——NVL返回值类型可能与col不兼容，触发隐式转换，导致索引失效 - 在视图或动态 SQL 里用
CASE WHEN col = NULL，因语法报错被拦截；但若写成CASE WHEN col IS NULL才正确，而DECODE对NULL的特例支持只适用于字面量，不可泛化 - 误用
DECODE(NVL(col, -1), -1, 'X', 'Y')替代空值判断，可能和真实数据中的-1冲突
大量分支时可读性差距远大于性能差距
当分支超过 10 个，维护成本就成为主要瓶颈：
-
DECODE(status, 'A', 'Active', 'I', 'Inactive', 'P', 'Pending', ..., 'Unknown')—— 参数成对堆砌，加删一个映射要重数位置，极易错位 -
CASE status WHEN 'A' THEN 'Active' WHEN 'I' THEN 'Inactive' ... ELSE 'Unknown' END—— 每行自包含，增删不影响其余，调试时单步也明确 - 分支内含函数调用（如
TO_CHAR(dt, 'YYYY-MM')）时，应提至外层计算一次再传入，否则重复执行——这点和用哪个函数无关，但CASE更容易看清执行边界
编译阶段的解析耗时差异（纳秒级）完全可忽略；真正拖慢交付的是改一行逻辑要花十分钟核对参数顺序，或是上线后发现某条空值路径始终走不到 ELSE 分支。
