COALESCE更值得优先使用，因其是ANSI标准函数、跨数据库兼容（PostgreSQL/MySQL 8.0+/SQL Server/SQLite均支持）、支持多参数链式兜底、类型推导更安全；而ISNULL仅SQL Server专属且仅两参数，CASE则冗长易错。
COALESCE 为什么比 ISNULL() 或 CASE 更值得优先用
COALESCE 是 SQL 标准函数，跨数据库兼容性好（PostgreSQL、MySQL 8.0+、SQL Server、SQLite 都支持），而 ISNULL() 是 SQL Server 特有，IFNULL() 只在 MySQL 里能用。它按从左到右顺序返回第一个非 NULL 的值，天然适合链式兜底。
注意：所有参数必须类型兼容，否则会触发隐式转换或报错（比如 COALESCE('a', 1) 在 PostgreSQL 中直接报错，而 SQL Server 可能转成字符串但结果不可控）。
- 推荐始终显式转换类型，例如
COALESCE(CAST(age AS VARCHAR), '未知') - 避免混用数值和字符串——哪怕看起来“能跑通”，也容易在迁移或升级时崩
- 第一个非
NULL值的类型决定整个表达式类型，后续参数会被强制转成该类型
怎么给字段 NULL 值统一设默认值（含常见错误）
最常用场景：查表时把空值替换成友好提示或业务默认值。别写成 COALESCE(column, '') 就完事——得看字段实际类型和下游用途。
- 对
INT字段，用COALESCE(price, 0)安全；但若业务上“0 元”和“价格未填”含义不同，那就不能这么干 - 对
DATE字段，COALESCE(created_at, '1970-01-01')虽语法合法，但可能干扰时间范围查询（比如WHERE created_at >= '2020-01-01'会意外包含兜底日期） - 千万别写
COALESCE(name, NULL)——这等于没写，毫无意义
嵌套 COALESCE 和性能影响
COALESCE 本身不慢，但嵌套过深或参数过多会拖慢执行计划，尤其在 WHERE 或 JOIN 条件里用时，可能让索引失效。
- 写成
WHERE COALESCE(status, 'draft') IN ('draft', 'active')比WHERE ISNULL(status, 'draft') IN (...)更可读，但两者都可能导致 status 索引无法使用 - 如果只是 SELECT 层面展示替换，放心用；但涉及过滤、排序、分组时，优先考虑提前清洗数据或加计算列
- 参数超过 5 个时建议拆开逻辑，比如先用 CTE 提前处理一层默认值，再用 COALESCE 补第二层
MySQL 和 PostgreSQL 对 COALESCE 的细微差异
绝大多数行为一致，但两个坑必须盯住：
- MySQL 8.0 之前，
COALESCE(NULL, NOW())每次调用都重新求值（即每行返回不同时间）；8.0+ 和 PostgreSQL 统一为“首次求值后复用”，但旧版本代码迁过来容易出时序 bug - PostgreSQL 要求所有参数类型能统一到一个公共类型，MySQL 更宽松——比如
COALESCE(1, '2')在 MySQL 返回字符串'1'，在 PostgreSQL 直接报错ERROR: COALESCE types integer and text cannot be matched - 测试时务必在目标数据库里跑真实数据验证，别只信本地开发环境
真正麻烦的不是语法怎么写，而是默认值语义是否和业务一致——比如把 NULL 替换成 0 后，统计平均值就失真了。先想清楚“这个 NULL 到底代表什么”，再决定要不要用 COALESCE。
