coalesce对join键无作用，仅用于join后结果字段的null处理；健壮join需用布尔逻辑重写on条件，如(a.key1 = b.key1) or (a.key1 is null and a.key2 = b.key2)；full join配合coalesce可合并双向缺失数据。
COALESCE不能保证JOIN键的健壮性，它只处理结果字段的NULL
直接说结论：COALESCE 对 ON 条件里的 JOIN 键本身毫无作用。它不参与连接逻辑，也不影响哪几行能匹配上。很多人误以为写成 ON COALESCE(a.id, 0) = COALESCE(b.id, 0) 就能“兜底”空值导致的连接失败——这是错的。JOIN 过程中，NULL = NULL 永远为 false（SQL 标准），所以哪怕两边都是 NULL，也不会被当作匹配行。此时 COALESCE 只是把 NULL 替换成某个值，再拿这个值去比，但原始数据语义已经丢失。
真正需要健壮 JOIN 键时，必须用条件逻辑重写 ON 子句
当业务允许“某字段为空时退而求其次用另一字段匹配”，就得放弃等值 =，改用布尔表达式组合：
ON (a.key1 = b.key1) OR (a.key1 IS NULL AND a.key2 = b.key2)- 如果还有第三级备选：
OR (a.key1 IS NULL AND a.key2 IS NULL AND a.key3 = b.key3) - 注意括号优先级，避免逻辑短路出错
- 这种写法会让执行计划变复杂，务必在所有参与字段上建复合索引，否则性能断崖下跌
COALESCE 在 JOIN 后的字段合并中才真正有用
它的价值体现在 JOIN 完成后，对结果集中可能为 NULL 的列做安全兜底，尤其配合 FULL JOIN 或 LEFT JOIN：
- 多源字段优先级合并：
COALESCE(e.email_work, e.email_personal, u.email_default, 'no-contact@domain.com') - 数值类兜底防计算中断：
COALESCE(o.amount, 0) * COALESCE(t.tax_rate, 0.0) - 注意类型隐式转换风险：如
COALESCE(1, 'abc')返回字符串'1'，后续参与数值运算会报错或静默转类型 - MySQL 中若只需两参数，
IFNULL更轻量；跨数据库项目则必须用COALESCE
FULL JOIN + COALESCE 是处理“双向缺失”的标准组合
当两张表都可能存在孤立记录（比如订单表有脏数据 user_id=6，用户表有未下单用户 id=5），又想合并展示全部信息时：
- 必须用
FULL JOIN（或 MySQL 中用LEFT JOIN UNION RIGHT JOIN模拟） -
COALESCE用来统一取名、取联系方式等字段：COALESCE(o.order_id, r.return_id) - 但别忘了显式过滤掉全为
NULL的无效行（比如WHERE COALESCE(o.id, r.id) IS NOT NULL） - 这种组合容易让初学者忽略数据来源歧义——结果里某条记录到底来自左表还是右表？建议加来源标识列
最常被忽略的点是：JOIN 健壮性从来不是靠函数兜底，而是靠清晰的业务规则映射到 SQL 逻辑。COALESCE 只是善后工具，不是连接引擎。
