coalesce不能修复join匹配逻辑，仅用于select阶段为已确定的null值提供默认值；其在on子句中滥用会导致left join语义失效、索引失效及性能下降。
COALESCE不能修复JOIN匹配逻辑，只能兜底输出值
直接说结论：COALESCE 在 ON 子句里用错位置，就会让 LEFT JOIN 变成 INNER JOIN。它根本不是用来“修复匹配”的函数，只负责在 SELECT 阶段把已经为 NULL 的字段换成默认值。
常见错误现象：写 LEFT JOIN b ON COALESCE(a.id, 0) = COALESCE(b.user_id, 0)，以为能连上两边都是 NULL 的行——结果是全表扫描、索引失效、性能暴跌，而且语义还错了（0 可能是真实存在的合法 ID）。
-
COALESCE只作用于单个表达式，不改变 JOIN 行为本身 - 真正决定“能不能连上”的，是
ON条件的布尔结果是否为TRUE；而NULL = NULL永远是UNKNOWN，不会触发连接 - 想让
NULL和NULL匹配，得用a.id IS NOT DISTINCT FROM b.user_id（PostgreSQL/MySQL 8.0.16+），或手写(a.id = b.user_id) OR (a.id IS NULL AND b.user_id IS NULL)
LEFT JOIN 后字段为 NULL，COALESCE 怎么写才安全
这才是 COALESCE 的正经用法：等 JOIN 完了，右表字段确实是 NULL 了，再给它填个默认值。
典型场景：查订单 + 用户昵称，用户没填昵称就显示“访客”。
- 必须显式限定字段来源：
COALESCE(u.nickname, '访客')，不能写成COALESCE(nickname, '访客')（列名歧义） - 参数类型要一致：
COALESCE(u.created_at, 'never')在 PostgreSQL 会报错，因为TIMESTAMP和TEXT不兼容；应改用TO_CHAR(u.created_at, 'YYYY-MM-DD') OR 'never'或统一转字符串 - 多字段优先级取值时，顺序就是业务优先级：
COALESCE(u.mobile, u.phone, u.email, '无联系方式') - 别在
WHERE里对COALESCE结果做判断：WHERE COALESCE(u.status, 'inactive') = 'active'会绕过索引，应直接过滤原始字段
空字符串和 NULL 混在一起时，ON 条件怎么写
很多业务数据里，'' 和 NULL 并存，但 '' = NULL 是 UNKNOWN，JOIN 直接跳过——这不是数据脏，是 SQL 标准行为。
正确做法是在 ON 两边统一清洗，而不是靠 COALESCE 做“匹配修复”。
- 推荐组合：
COALESCE(NULLIF(TRIM(a.key), ''), '') = COALESCE(NULLIF(TRIM(b.key), ''), '') -
NULLIF(col, '')把空字符串转成NULL，COALESCE(..., '')再把NULL统一补成''，确保两边可比 - 注意：
TRIM(NULL)还是NULL，所以不能只写TRIM(a.key) = TRIM(b.key) - 大数据量时，记得建函数索引，比如 MySQL：
CREATE INDEX idx_clean_key ON table_a ((TRIM(key)));
嵌套 JOIN 或子查询里，COALESCE 容易漏掉哪一层
三张表连查：orders → users → profiles，想给 profiles.bio 补默认值，但发现 COALESCE(p.bio, '暂无介绍') 有时还是 NULL。
问题出在中间层断链：如果 users 没匹配上，p.bio 就根本不会出现在结果里（整行 p.* 全是 NULL），COALESCE 拿不到任何值。
- 必须逐层包裹：
COALESCE(u.name, '未知用户')和COALESCE(p.bio, '暂无介绍')要分开写，不能合并成一个COALESCE - 标量子查询要特别小心：
COALESCE((SELECT bio FROM profiles WHERE user_id = u.id), '暂无介绍')，括号不能少，否则COALESCE会去包整个SELECT语句，语法错误 - 验证方法：先跑不带
COALESCE的查询，看目标字段是否真有NULL值；没有NULL，说明问题不在这里，而在 JOIN 逻辑或数据本身
ON 阶段）、是结果缺失（SELECT 阶段）、还是数据混杂（'' 和 NULL 并存）。每种情况对应不同的解法，混用就会出错。
