coalesce 是跨数据库最稳妥的空值处理函数，支持多参数、符合sql标准，且在mysql、oracle、postgresql中均被广泛支持；ifNULL和nvl则分别为mysql和oracle方言函数，存在类型严格性与兼容性差异。
MySQL 里写 IFNULL，Oracle 里不能直接抄过去用
因为 NVL 是 Oracle 特有的函数，MySQL 不认；反过来 IFNULL 在 Oracle 里会报 ORA-00904: "IFNULL": invalid identifier。这不是语法写错，是数据库方言差异——就像 Python 的 len() 和 JavaScript 的 .Length，名字不同、行为也不完全一致。
常见错误现象：把 Oracle 脚本原封不动跑在 MySQL 上，或反之，卡在第一个空值处理就失败。
-
IFNULL(expr1, expr2)：MySQL / mariadb 支持，只接受两个参数，expr1为NULL时返回expr2 -
NVL(expr1, expr2)：Oracle / PostgreSQL（需启用兼容模式）支持，语义相同，但 Oracle 对参数类型要求更严格——两个参数必须类型兼容，否则报ORA-00932 - PostgreSQL 默认不支持这两个，得用
COALESCE(expr1, expr2)，它支持任意多参数，且是 SQL 标准函数
COALESCE 是跨数据库最稳的空值替代方案
如果你写的 SQL 要在多个数据库间迁移，或者团队里 MySQL 和 Oracle 并存，COALESCE 就是那个“少踩坑”的选择。它不挑数据库，语义清晰，而且比 IFNULL / NVL 更灵活。
使用场景：字段可能为空，需要 fallback 值，又不确定最终部署在哪种数据库上。
-
COALESCE(col, 'N/A', '')：返回第一个非NULL值，支持多个备选，IFNULL和NVL都做不到 - 性能上三者差别极小，但
COALESCE在 Oracle 中会被优化为类似NVL的执行计划，不用担心慢 - 注意：所有参数会被隐式转换类型，比如
COALESCE(int_col, 'unknown')在 PostgreSQL 中会报错类型冲突，MySQL 可能静默转成字符串，Oracle 则要求显式一致
Oracle 里用 NVL 却遇到类型不匹配报错
典型错误信息：ORA-00932: inconsistent datatypes: expected number got char。不是你逻辑错了，是 Oracle 对 NVL 两个参数的类型一致性要求非常死板。
比如想把空数字转成字符串提示，写成 NVL(salary, 'N/A') 就会崩——salary 是 NUMBER，'N/A' 是字符，Oracle 不自动转。
- 正确做法：统一类型，要么都转成字符：
NVL(TO_CHAR(salary), 'N/A') - 要么都保持数字：
NVL(salary, -1)，再在应用层解释 -1 为空 - 别依赖
NVL2来绕开——它只是多一个条件分支，不解决类型问题 - MySQL 的
IFNULL类型宽容得多，IFNULL(123, 'missing')能直接返回字符串，但这恰恰是迁移时最容易翻车的地方
什么时候非得用 IFNULL 或 NVL，而不是 COALESCE
只有两种情况值得破例：一是老系统强约束，SQL 必须适配某个数据库的旧版本（比如 MySQL 5.0 不支持 COALESCE？其实它早支持了，这其实是误解）；二是性能敏感路径，且已确认执行计划有差异——但现实中极少。
真实情况是：很多人坚持用 IFNULL 只是因为习惯了，或者从某篇过时博客抄来的写法。
- MySQL 5.7+、Oracle 10g+、PostgreSQL 8.0+ 全都支持
COALESCE，且标准更可靠 -
IFNULL在某些 MySQL 版本中对 json 字段处理有 bug，COALESCE更稳定 - 如果必须用
NVL（比如 Oracle dba 强制规范），那就全程用 Oracle 类型思维写，别混用字符串和数字
空值处理看着简单，但类型隐式转换、数据库方言、执行计划这几块，随便漏掉一个，上线后查半天才发现是 NVL 把数字转成字符串导致索引失效。