COALESCE仅在SELECT阶段替换已确定为NULL的字段，不能修复JOIN逻辑；必须置于SELECT中，不可用于ON或WHERE；其生效前提是LEFT JOIN后右表字段确实为NULL。
COALESCE不能修复JOIN逻辑，只负责在SELECT阶段把已确定为NULL的字段换成默认值；用错位置会让LEFT JOIN语义失效，甚至变成全表扫描。
COALESCE必须写在SELECT里，不能塞进ON或WHERE
LEFT JOIN后右表字段为NULL，是COALESCE起效的唯一前提。如果把它挪到ON条件里，比如ON a.id = COALESCE(b.user_id, 0)，不仅无法匹配NULL，还会让数据库放弃索引、强制扫描全表。
- 正确做法：保持
ON只做纯等值关联，如ON a.user_id = b.id - COALESCE只包裹SELECT中的目标字段，如
COALESCE(b.status, 'pending') - 若需过滤右表数据（如只取
b.status = 'done'），必须移到WHERE或子查询中，否则LEFT JOIN退化为INNER JOIN
多表嵌套时，COALESCE要逐字段、逐层级包裹
连查三张表（orders → users → departments）时，不能指望一个COALESCE(u.name, d.name, 'N/A')兜底所有层级——u.name为NULL时，d.name根本不会存在（因为u没连上，d自然没数据）。
- 必须分步处理：
COALESCE(u.name, 'guest')和COALESCE(d.name, 'unassigned')各自独立包裹 - 字段来源必须显式限定，避免歧义，如不能写
COALESCE(name, 'N/A')，而应写COALESCE(u.name, 'N/A') - 类型不兼容会直接报错，例如
COALESCE(u.created_at, 'never')在PostgreSQL中失败，需先转字符串：COALESCE(TO_CHAR(u.created_at, 'YYYY-MM-DD'), 'never')
空字符串和NULL混存时，ON条件得先清洗再比较
业务数据里''和NULL并存很常见，但'' = NULL永远是UNKNOWN，JOIN直接跳过——这不是数据脏，是SQL标准行为。
- 正确写法是两边统一清洗：
COALESCE(NULLIF(TRIM(a.key), ''), '') = COALESCE(NULLIF(TRIM(b.key), ''), '') -
NULLIF(col, '')把空字符串转成NULL，COALESCE(, '')再把NULL补成''，确保可比 - 别只写
TRIM(a.key) = TRIM(b.key)，因为TRIM(NULL)仍是NULL，比较仍失败 - 大数据量时，记得建函数索引，如MySQL：
CREATE INDEX idx_clean_key ON table_a ((TRIM(key)));
最容易被忽略的是：COALESCE生效的前提，是字段**确实为NULL**，而这个NULL必须来自JOIN本身的逻辑结果——不是你“以为它该是NULL”，而是执行计划里右表那行压根没匹配上。验证方法很简单：先跑一遍不带COALESCE的原始查询，用IS NULL确认目标字段真有NULL值，再加。否则，全是白忙。
