coalesce更适合多字段兜底因其符合sql标准、跨库兼容且天然支持链式取值；但需注意类型兼容性、空字符串无效、where中索引失效及复杂逻辑应改用case。
COALESCE 为什么比 ISNULL 或 CASE 更适合多字段兜底？
COALESCE 是 SQL 标准函数，跨数据库兼容性好（PostgreSQL、MySQL 8.0+、SQL Server、Oracle 都支持），而 ISNULL 是 SQL Server 特有，IFNULL 只在 MySQL 里可用。它按从左到右顺序返回第一个非 NULL 的值，天然适合“优先取 A，A 没值就取 B，B 也没值就取 C”的链式兜底场景。
常见错误是误以为 COALESCE 能自动类型转换——其实它要求所有参数类型兼容，否则会报错，比如 COALESCE(col1, 'N/A') 中 col1 是 INT，就会触发隐式转换失败（尤其在 PostgreSQL 和严格模式的 MySQL 中）。
- 必须确保所有参数能隐式转成同一类型，或显式用
CAST统一，例如：COALESCE(CAST(age AS TEXT), 'unknown') - 参数列表至少两个表达式，写成
COALESCE(col)会报语法错误 - 空字符串
''不等于NULL，所以COALESCE(name, 'anonymous')对name = ''的行不生效
在 SELECT 和 WHERE 中使用 COALESCE 的典型差异
SELECT 里用 COALESCE 主要是修饰输出结果，比如把 NULL 显示为默认值；而 WHERE 里用它容易引发性能陷阱——因为对列应用函数会导致索引失效。
例如：WHERE COALESCE(status, 'active') = 'active' 会让 status 字段无法走索引；更安全的写法是：WHERE status = 'active' OR status IS NULL。
-
SELECT场景：安全，常用于报表展示，如COALESCE(phone, email, 'no contact info') -
WHERE场景：慎用，优先拆解为OR条件，除非配合函数索引（如 PostgreSQL 的表达式索引） - ORDER BY 中用 COALESCE 会影响排序逻辑，比如
ORDER BY COALESCE(updated_at, created_at)，需确认业务是否真需要这个 fallback 时间
COALESCE 处理日期、数值、字符串时的类型陷阱
不同数据类型混用 COALESCE 时，数据库按自身规则决定返回类型，可能和预期不符。比如 SQL Server 中 COALESCE(date_col, GETDATE()) 返回 DATETIME，但若 date_col 是 DATE，结果会带时间部分，影响比较逻辑。
- 日期字段兜底：建议统一用
CAST显式转为目标精度，如COALESCE(CAST(due_date AS DATE), CURRENT_DATE) - 数值字段兜底：注意
NULL和0语义不同，COALESCE(price, 0)把缺失价当成免费，可能误导统计 - 字符串字段兜底：避免直接拼接，比如
COALESCE(first_name, '') || ' ' || COALESCE(last_name, '')在任一字段为NULL时会得到多余空格，应改用CONCAT或嵌套 COALESCE
替代方案：什么时候该放弃 COALESCE？
当兜底逻辑复杂（比如依赖其他字段、需要条件判断），或者要处理空字符串和 NULL 两种“空”状态时，COALESCE 就力不从心了。这时候 CASE WHEN 更清晰可控。
例如：既要处理 NULL，又要把空字符串视同缺失，就得写：CASE WHEN name IS NULL OR name = '' THEN 'unnamed' ELSE name END —— COALESCE 对 '' 完全无感。
- 涉及业务规则判断（如“若 state 为 NULL，则根据 country 推导默认值”）必须用
CASE - 需要返回不同类型的值（比如 NULL → 返回字符串，非 NULL → 返回整数）只能靠
CASE，COALESCE 强制类型一致 - 嵌套太深的 COALESCE（超过 4–5 层）可读性骤降，不如拆成 CTE 或子查询预处理
COALESCE 看似简单，但类型推导、索引影响、空字符串盲区这些点，实际查线上慢 SQL 或导出错数据时，往往就卡在这几处。
