应优先选coalesce，因其跨数据库兼容、支持多参数链式fallback且类型处理更稳健；nvl仅oracle专用、限两参数、隐式转换易出错。
直接用 COALESCE，除非你确定只跑 Oracle 且逻辑永远只需要两个值——否则 NVL 是个隐性兼容雷。
Oracle 视图里该选 NVL 还是 COALESCE？
选 COALESCE 更稳妥。它在 Oracle、PostgreSQL、SQL Server、MySQL 8.0+ 都能用，而 NVL 是 Oracle 独占函数，一旦视图被迁到其他数据库或对接 BI 工具（比如 Tableau 直连 PostgreSQL），NVL 会直接报错 function nvl does not exist。
-
COALESCE支持任意多个参数，比如COALESCE(mobile, work_phone, home_phone, 'N/A')，写一次就覆盖多层 fallback -
NVL只能写两层，想模拟三层就得嵌套：NVL(mobile, NVL(work_phone, 'N/A'))，可读性和维护性都差 - 两者都遵循“短路求值”：遇到第一个非 NULL 就停，不会继续计算后面参数（这点和
NVL2不同，NVL2会评估全部三个参数）
NVL 在视图定义中容易踩的类型陷阱
NVL 要求两个参数类型严格兼容，Oracle 会尝试隐式转换，但结果常出人意料。比如把字符串和数字混用：
SELECT NVL(salary, 'N/A') FROM employees;
如果 salary 是 NUMBER 类型，Oracle 会把 'N/A' 强转成数字，报错 ORA-01722: invalid number。
- 显式转换更安全：
NVL(TO_CHAR(salary), 'N/A')或NVL(salary, 0) - 日期字段别用字符串兜底：
NVL(hire_date, '1900-01-01')会触发隐式转换，改用NVL(hire_date, DATE '1900-01-01') - 视图一旦创建，类型检查就固化了；后续表结构微调（比如字段从
NUMBER改成NUMBER(10,2)）可能让原有NVL表达式失效
为什么 COALESCE 的参数类型要求反而更宽松？
COALESCE 的返回类型由参数列表中“优先级最高”的非 NULL 类型决定，Oracle 按预设顺序选择（比如 DATE > NUMBER > VARCHAR2），所以即使混写也不会立即报错，但结果可能不是你想要的。
- 例如：
COALESCE(TO_DATE('2020-01-01'), 123)返回DATE类型，而123会被转成日期（通常是 123 天后的系统日期） - 安全做法是统一类型：
COALESCE(TO_CHAR(date_col), TO_CHAR(num_col), 'unknown') - 注意：所有参数仍需能被 Oracle 转成同一类型，否则建视图时直接失败，不等运行
视图性能与空值函数的真实影响
在视图里用 NVL 或 COALESCE 本身不拖慢查询，但它们会阻止相关字段走索引——尤其是当函数出现在 WHERE 子句里时（比如 WHERE NVL(status, 'active') = 'active'）。但在 SELECT 列中单纯做显示替换，影响几乎为零。
- 真正要小心的是在视图定义里嵌套复杂表达式，比如
NVL(compute_tax(amount), 0)，每次查视图都会执行函数 - 如果视图被频繁 JOIN 或用于物化视图刷新，建议把空值处理下推到基表层（如用
DEFAULT约束或触发器填充默认值），而不是全靠视图层函数兜底 -
COALESCE的多参数链在执行计划里仍是一次性判断，没有额外开销，比等价的CASE表达式略轻量
最常被忽略的一点：视图里的空值函数不会改变底层数据，也不会影响约束行为；如果你依赖 COALESCE 来“掩盖”缺失字段，却忘了在应用层同步校验业务规则，问题只是延后爆发而已。
