COALESCE更可靠，因其是SQL标准函数，被PostgreSQL、MySQL 8.0+、SQL Server、Oracle、SQLite等所有主流数据库统一支持；而ISNULL仅SQL Server支持，IFNULL仅MySQL支持，跨库迁移必报错。
COALESCE 为什么比 ISNULL 或 IFNULL 更可靠？
因为 COALESCE 是 SQL 标准函数，所有主流数据库（PostgreSQL、MySQL 8.0+、SQL Server、Oracle、SQLite）都支持，而 ISNULL（SQL Server 专属）和 IFNULL（MySQL 专属）无法跨平台移植。更关键的是，COALESCE 按从左到右顺序求值，遇到第一个非 NULL 表达式就立即返回，不计算后续参数——这对含副作用的表达式（比如子查询或函数调用）很关键。
常见错误是误以为 COALESCE(col, 'N/A') 能处理空字符串 ''：它不能。COALESCE 只判断 NULL，对空字符串、零值、空白字符一概无视。
怎么用 COALESCE 处理多层嵌套的 NULL？
当字段可能来自多表 JOIN，且多个来源都可能为 NULL 时，COALESCE 的多参数能力就凸显出来。例如用户地址信息分散在 users、profiles、settings 三张表中：
SELECT name, COALESCE(p.address, s.default_address, '未填写地址') AS final_address FROM users u LEFT JOIN profiles p ON u.id = p.user_id LEFT JOIN settings s ON u.id = s.user_id;
注意点：
-
COALESCE所有参数必须兼容数据类型，否则数据库会尝试隐式转换——PostgreSQL 严格报错，MySQL 可能静默转成字符串导致意外结果 - 如果所有参数都是 NULL，
COALESCE返回 NULL，不会自动 fallback 到空字符串 - 避免写
COALESCE(col, '')试图“清空 NULL”，这其实只是把 NULL 转成空字符串，语义上仍是“无值”而非“有值但为空”
COALESCE 在 WHERE 和 ORDER BY 中的陷阱
在过滤或排序时直接用 COALESCE 容易引发性能问题或逻辑偏差。例如：
WHERE COALESCE(updated_at, created_at) > '2024-01-01'
这个条件无法有效利用 updated_at 或 created_at 的索引（多数数据库不支持函数索引，除非显式创建）。更糟的是，如果 updated_at 是 NULL，就会退回到 created_at，可能查出本不该出现的旧记录。
推荐做法：
- 在
WHERE中优先用原生比较：(updated_at > '2024-01-01') OR (updated_at IS NULL AND created_at > '2024-01-01') - 如必须用
COALESCE排序，确认目标列已建函数索引（如 PostgreSQL 的CREATE INDEX idx_coalesce ON tbl ((COALESCE(updated_at, created_at)))） - 别在
ORDER BY里混用COALESCE和NULLS LAST，不同数据库对 NULL 的排序行为不一致
和 CASE WHEN 相比，什么时候该选 COALESCE？
COALESCE(a, b, c) 等价于 CASE WHEN a IS NOT NULL THEN a WHEN b IS NOT NULL THEN b ELSE c END，但前者更简洁、意图更明确。不过一旦逻辑变复杂，比如需要判断空字符串、负数、特定标记值（如 'UNKNOWN'），就必须换 CASE：
SELECT
CASE
WHEN status IS NULL THEN 'pending'
WHEN status = '' THEN 'empty'
WHEN status IN ('N/A', 'UNKNOWN') THEN 'invalid'
ELSE status
END AS normalized_status
FROM orders;
这时候硬套 COALESCE 不仅写不出来，还会掩盖业务语义。记住：COALESCE 只管 NULL，不管业务意义上的“无效值”。
