优先用coalesce，因其符合sql标准、支持多参数、短路求值更安全高效；nvl仅在需隐式类型转换或兼容遗留pl/sql时选用。
优先用 COALESCE，除非你明确需要 NVL 的隐式类型转换，或正在维护大量已有 NVL 嵌套的旧代码。
为什么 COALESCE 在多数场景下更安全可靠
COALESCE 是 SQL 标准函数，所有主流数据库（PostgreSQL、SQL Server、MySQL 8.0+）都支持；NVL 是 Oracle 专属。更重要的是语义差异：COALESCE(expr1, expr2, expr3) 从左到右求值，一旦 expr1 非 NULL，expr2 和 expr3 **完全不执行**——这直接规避三类风险：
- 耗时计算白跑：比如
COALESCE(col, heavy_calculation())，若col有值，heavy_calculation()根本不调用 - 无谓异常：如
COALESCE(col, TO_NUMBER(some_str))，some_str若含非法字符，仅当col IS NULL时才触发 ORA-01722 - 意外 IO：含子查询或 DBLINK 访问的参数，不会因兜底逻辑被强制执行
NVL 和 COALESCE 对数据类型的处理差异
NVL 允许两个参数类型不同，Oracle 会尝试隐式转换（例如 NVL(date_col, '1970-01-01') 可能成功，但行为依赖当前 NLS_DATE_FORMAT）；COALESCE 要求所有参数**类型兼容且可统一为一种类型**，否则直接报 ORA-00932。
这意味着：
-
COALESCE(col_date, SYSDATE, NULL)✅ 合法（三者都是 DATE） -
COALESCE(col_date, '2024-01-01', NULL)❌ 报错——字符串字面量不是 DATE，Oracle 不会“猜”格式 -
NVL(col_date, '2024-01-01')可能侥幸通过，但跨库迁移或会话 NLS 设置变更时极易失效
哪些情况必须用 NVL，不能用 COALESCE
真实存在的例外场景极少，但确实存在：
- PL/SQL 函数体内对
IN OUT或OUT变量赋值：COALESCE只接受表达式，无法直接用于变量绑定；而NVL(v_var, default_val)可嵌入赋值链 - 遗留系统中堆叠多层
NVL(NVL(NVL(...)))，临时替换为COALESCE需同步校验所有分支类型一致性，风险高于收益 - 极少数报表逻辑依赖
NVL(varchar2_col, 0)这类松散隐式转换（不推荐，但改写需业务确认）
容易被忽略的 NULL 传播与运算陷阱
NVL 和 COALESCE 只解决“单点兜底”，不阻断 NULL 在整条表达式中的传播：
-
SELECT NVL(price, 0) * qty FROM orders：若qty IS NULL，结果仍是 NULL——NVL没法保护乘法运算本身 -
AVG(NVL(salary, 0))vsAVG(salary)：前者把所有 NULL 行当 0 纳入分母，后者直接剔除，业务含义可能天差地别 -
WHERE col = NULL永远不成立，必须写成WHERE col IS NULL；哪怕你刚用NVL包装过该列，原始判定逻辑不变
真正关键的不是选哪个函数，而是想清楚：你是在做类型安全的空值替换，还是在掩盖未定义的业务逻辑分支——后者靠函数兜不住。
