coalesce 最合理用于从多个可能为 null 的字段中短路返回首个非空值，如用户资料中优先取 mobile、次选 wechat、最后 email；要求参数类型兼容，不判空字符串或零值，慎用于 where/order by 以免索引失效。
COALESCE 用在哪种场景下最合理
当你要从多个可能为 NULL 的字段中取第一个非空值时，COALESCE 是最直接的选择。它不是为了“拼接字符串”，也不是为了“兜底默认值”而存在——它的核心是“短路返回首个非空表达式”。常见于：用户资料表里 mobile、wechat、email 三字段都可能为空，但你想优先展示手机号，没手机号就用微信，再没有就用邮箱。
COALESCE 的参数必须类型兼容
数据库会按顺序检查每个参数，一旦遇到非空值就立刻返回，但所有参数必须能隐式转换为同一类型，否则报错。比如 PostgreSQL 会拒绝 COALESCE(name, 123)（text 和 integer 无法统一），MySQL 可能强制转成字符串但结果不可控。
- 推荐显式转换：
COALESCE(CAST(age AS TEXT), '未知') - 避免混用数字和字符串：
COALESCE(price, 'N/A')在多数数据库里会失败 - 日期字段慎用：
COALESCE(created_at, '1970-01-01')需确保字符串能被正确解析为日期
COALESCE 和 CASE WHEN 哪个更可控
COALESCE 是语法糖，底层等价于嵌套的 CASE WHEN，但它不支持条件判断逻辑。如果你需要“非空但值为 '0' 的也算无效”，COALESCE 就无能为力了，必须用 CASE。
例如：想把空值或字符串 '0' 都跳过，选下一个字段：
COALESCE(NULLIF(phone, '0'), NULLIF(wechat, '0'), email)
这里 NULLIF 先把 '0' 变成 NULL，再交给 COALESCE 处理——这是常见组合技。
-
COALESCE只判NULL，不判空字符串、零值、空白符 - 需要业务级“无效值过滤”时，必须前置清洗（
NULLIF、TRIM、CASE） - 嵌套太深（>5 层）会影响可读性，此时建议拆成 CTE 或视图
性能和索引影响容易被忽略
COALESCE 本身不阻止索引使用，但如果写在 WHERE 或 ORDER BY 中，尤其是包裹了字段的表达式，会导致索引失效。例如：WHERE COALESCE(status, 'pending') = 'active' 无法走 status 字段的索引。
- 尽量把
COALESCE放在SELECT列里，而非过滤或排序条件中 - 如果必须用于查询条件，考虑加函数索引（PostgreSQL）或生成列（MySQL 5.7+）
- 在 JOIN 条件中用
COALESCE(a.id, b.fallback_id) = c.id会显著拖慢执行计划，应重构关联逻辑
真正麻烦的是嵌套调用和跨表字段混合，这时候执行计划里常出现 Seq Scan 或 Full Table Scan——得看 EXPLAIN，不能只信语义。
