COALESCE是处理NULL的基础安全带，需严格按从左到右顺序使用，确保非NULL值优先被选中，所有参数必须类型兼容，不可用于WHERE或JOIN条件中替代逻辑判断，空字符串等伪空值须先用NULLIF清洗。
COALESCE 不是“锦上添花”的修饰函数，它是处理 NULL 的基础安全带——用错顺序、塞进 WHERE、忽略类型兼容性，结果立刻失真。
COALESCE 参数顺序写错，兜底就完全失效
它严格从左到右扫描，遇到第一个非 NULL 值立即返回，后续参数彻底不执行。这意味着：谁放前面，谁优先被选中。
- LEFT JOIN 后的关联字段（如
t2.phone）天然易为NULL，必须放在靠左位置才能真正参与兜底 - 错误写法：
COALESCE('N/A', t2.phone)→ 永远返回'N/A'，t2.phone再非空也无效 - 正确写法：
COALESCE(t2.phone, t1.backup_phone, '未提供')→ 逐级 fallback，语义清晰 - 聚合前兜底更符合业务意图：
SUM(COALESCE(sales, 0))是每行补 0 再求和；COALESCE(SUM(sales), 0)是整列全NULL才补 0，二者统计口径完全不同
所有参数必须类型兼容，否则强类型数据库直接报错
PostgreSQL、SQL Server 等不会隐式转换；MySQL 虽尝试转换，但结果不可控（比如把数字转成字符串再拼接）。
- 常见报错：
cannot cast type integer to text（PostgreSQL）、Illegal mix of collations（MySQL） - 危险写法：
COALESCE(name, age)→ 字符串 vs 整数，多数库拒绝执行 - 安全写法：
COALESCE(CAST(age AS TEXT), '未知')或统一用字符串：COALESCE(name, '—', '未知') - 数字字段兜底用
0，字符串字段兜底用''或'N/A'，别交叉混用
别在 WHERE 或 JOIN 条件里用 COALESCE “修复”逻辑
它只作用于 SELECT 投影阶段的显示值，对数据匹配过程毫无影响。滥用会扭曲语义、绕过索引、甚至让 LEFT JOIN 退化为 INNER JOIN。
- 危险写法：
WHERE COALESCE(status, 'active') = 'shipped'→ 实际过滤掉所有status IS NULL行 - 等效错误逻辑：
WHERE status = 'shipped' OR status IS NULL→ 本意是查 shipped，结果把 NULL 也拉进来了 - 正确做法：筛选条件写进
ON子句（如ON t1.id = t2.order_id AND t2.status = 'shipped'），显示层再用COALESCE - 若真需覆盖 NULL 的等值判断，应拆成显式条件：
WHERE status = 'shipped' OR (status IS NULL AND fallback_flag = 1)
空字符串 ''、占位符 'NULL' 不是 NULL，得先用 NULLIF 清洗
COALESCE 对 ''、'NULL'、' ' 这类“伪空值”完全无感——它们是合法字符串，不是 SQL 的 NULL。
- 错误写法：
COALESCE(phone, '未提供')→ 若phone = ''，结果仍是空字符串 - 正确链式写法：
COALESCE(NULLIF(TRIM(phone), ''), '未提供')→ 先去空格，再把空字符串转为NULL，最后兜底 -
NULLIF(a, b)在a = b时返回NULL，否则返回a，是轻量但关键的前置清洗工具 - 注意
TRIM()兼容性：PostgreSQL 和 MySQL 5.7+ 支持标准写法；旧版 MySQL 需用TRIM(BOTH ' ' FROM phone)
最常被忽略的一点：COALESCE 的每个参数都可能触发计算（比如子查询、函数调用），而它只保证“短路”——一旦命中非 NULL 就停。但如果你把高开销操作放在左边，它就会被执行；放在右边，可能永远不执行。顺序不仅是语义问题，也是性能开关。
