coalesce仅在select阶段处理已连接结果中的null，不参与join匹配；on中使用coalesce会破坏语义、降低性能且无法走索引，正确用法是在left join后对输出字段做安全兜底。
COALESCE 不参与缺失值匹配，它只在 SELECT 阶段处理已连接完成的结果字段中的 NULL；真正影响“是否能匹配上”的是 ON 条件逻辑，不是函数兜底。
为什么 ON COALESCE(a.id, 0) = COALESCE(b.id, 0) 是错的
这个写法看似“让空 ID 也能连上”，实则破坏业务语义且无效：
-
NULL = NULL在 SQL 中恒为FALSE，所以COALESCE只是在等号左边和右边各替换一次值，再拿两个非NULL值去比——比如把NULL和NULL都变成0，结果变成0 = 0，看似连上了，但实际是把两条本不该关联的记录强行绑在一起 - 如果 a.id 是
NULL、b.id 是5，那表达式变成0 = 5，直接断连，反而比原本更糟 - 数据库无法对
COALESCE(a.id, 0)这类表达式走索引，JOIN 性能会断崖下跌
LEFT JOIN 后用 COALESCE 做安全兜底的正确姿势
这是 COALESCE 最常见也最稳妥的使用场景：右表字段因没匹配而为 NULL，你在最终输出时给个默认值。
- 优先级必须合理：比如联系人字段，应是
COALESCE(t2.work_email, t1.personal_email, 'no-email@domain.com')，而不是反过来 - 类型要显式统一：若
t2.phone是VARCHAR(20)，兜底字符串就得控制长度，避免下游 BI 误判字段宽度 - 空字符串要先清洗：写成
COALESCE(NULLIF(TRIM(t2.phone), ''), NULLIF(TRIM(t1.mobile), ''), 'not provided') - 别省略表前缀：
COALESCE(users.email, orders.email, '—')比COALESCE(email, '—')更安全，避免作用域混淆
多源字段合并时 COALESCE 的三个硬前提
你不能只看“都是字符串”就往里塞，必须同时满足：
- 语义一致：比如
o.status、m.status、d.default_status都代表“当前订单状态”，不是“订单状态”“会员等级”“配送方式”混着来 - 优先级明确：顺序即业务规则，
COALESCE(o.status, m.status, d.default_status)意味着“以订单表为准，缺了才看会员表，再缺才用默认值” - 类型兼容或已强制转换：例如
COALESCE(CAST(o.amount AS DECIMAL(18,2)), 0.00)，避免隐式转类型导致精度突变
WHERE 或 ON 里滥用 COALESCE 的后果
这是线上事故高发区：
-
WHERE COALESCE(status, 'active') = 'active'→status列无法走索引，全表扫描风险极高 - 应拆成：
WHERE status = 'active' OR status IS NULL -
ON COALESCE(a.key, b.fallback_key) = c.id→ 执行计划完全不可控，复合索引失效，JOIN 变成嵌套循环暴力匹配 - 真需要多键 fallback，请用布尔逻辑：
ON (a.key = c.id) OR (a.key IS NULL AND b.fallback_key = c.id)，并确保a.key和b.fallback_key上有联合索引
