DECODE是Oracle专有函数，仅在Oracle及部分兼容数据库中可用，用于简化条件分支，不支持SQL标准，跨库迁移需替换为CASE WHEN；参数须成对且结果类型兼容，不支持复杂表达式判断。
DECODE在Oracle中怎么用，为什么别在其他数据库里试
DECODE是Oracle专有函数，只在Oracle和部分兼容Oracle的数据库（如某些版本的OceanBase）中可用。它本质是简化的条件分支，但不支持SQL标准，MySQL、PostgreSQL、SQL Server里直接写会报错：ORA-00904: "DECODE" invalid identifier 或类似提示。
常见误用场景：把Oracle脚本直接迁到MySQL后，DECODE(status, 'A', 'Active', 'I', 'Inactive', 'Unknown') 报错。这时候不能改语法，得换函数。
- 只适用于Oracle；跨库迁移前必须替换
- 参数必须成对出现（value, result），最后可加一个默认值（else_result）
- 所有result表达式类型需兼容，否则隐式转换可能出错，比如混用字符串和数字：
DECODE(x, 1, 'yes', 2, 0)在某些版本会报类型冲突 - 不支持复杂表达式作为判断条件，比如不能写
DECODE(x > 10, true, 'big', 'small')
CASE WHEN比DECODE更通用，但写法细节决定是否出错
CASE 是SQL标准语法，所有主流数据库都支持，但具体行为有细微差别。最稳妥的是使用**搜索型CASE**（即带布尔表达式的写法），而不是简单型CASE（类似DECODE的等值匹配）。
错误示范：CASE status WHEN 'A' THEN 'Active' WHEN 'I' THEN 'Inactive' ELSE 'Unknown' END —— 这种简单型CASE在PostgreSQL里要求status和字面量类型严格一致，如果status是CHAR(1)而写成'A'（VARCHAR），可能触发隐式转换失败。
- 优先用搜索型CASE：
CASE WHEN status = 'A' THEN 'Active' WHEN status = 'I' THEN 'Inactive' ELSE 'Unknown' END - 每个
WHEN子句独立求值，支持任意布尔表达式，比如WHEN amount > 1000 AND currency = 'USD' -
ELSE不是可选的——不写的话，不满足任何条件时返回NULL，容易引发后续逻辑空值问题 - MySQL 5.7+ 对
CASE结果列推导类型较严格，若各THEN分支返回不同类型（如'text'和123），会尝试转成通用类型，可能导致截断或警告
性能差异真有吗？看执行计划再下结论
很多人以为DECODE比CASE快，其实Oracle内部早已把两者优化成相同执行路径。真正影响性能的是分支逻辑复杂度和索引利用情况，不是函数名本身。
例如：CASE WHEN order_date >= DATE '2024-01-01' THEN 'New' ELSE 'Old' END 如果order_date没索引，这个表达式本身不拖慢查询；但如果把它放到WHERE里当过滤条件：WHERE CASE WHEN ... THEN 1 ELSE 0 END = 1，就可能让优化器放弃索引走全表扫描。
- 避免在
WHERE或JOIN ON中用CASE/DECODE包装字段做等值判断 - 需要按条件分组统计时，
GROUP BY CASE...是安全的，优化器通常能正确处理 - PostgreSQL中，
CASE表达式若含子查询（如WHEN (SELECT count(*) FROM log WHERE log.id = t.id) > 0），会显著拖慢性能，应提前物化或改用LEFT JOIN
字符串拼接+条件列？小心NULL传播和类型隐式转换
实际业务中常遇到“根据状态拼接不同前缀”，比如：'Order-' || DECODE(status, 'A', 'ACT', 'I', 'INV') || order_id。这里有两个隐形陷阱：一是DECODE返回NULL时，整个拼接结果变NULL；二是在SQL Server里用+拼接，遇到NULL直接得NULL，而MySQL用CONCAT()会跳过NULL。
- Oracle/PostgreSQL建议统一用
COALESCE兜底：'Order-' || COALESCE(DECODE(status, 'A', 'ACT', 'I', 'INV'), 'UNK') || order_id - SQL Server中，
ISNULL(DECODE(...), 'UNK')比COALESCE更高效（前者单次类型推导） - MySQL 8.0+ 支持
COALESCE，但老版本建议用IFNULL，且注意CONCAT('A', NULL, 'B')返回NULL，不是'AB'
最麻烦的其实是多层嵌套条件和字符串操作混用，比如先CASE判断再TRIM再拼接——这种逻辑一旦字段为空或类型异常，排查起来要翻好几层执行计划。不如拆成CTE或临时列，把条件判断和字符串处理分开。
