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值，再加。否则，全是白忙。