COALESCE不能替代JOIN，仅用于表达式级空值替换；必须配合显式LEFT JOIN实现多表优先级取值，且JOIN顺序、索引和业务语义共同决定实际优先级。
COALESCE 不能直接替代 JOIN，但能简化多表优先级取值
很多人以为 COALESCE 可以“自动从多个表里找第一个非空值”，其实它只作用于表达式列表，不触发表连接。真正实现“按优先级查表”必须配合显式 LEFT JOIN，再用 COALESCE 合并字段结果。
典型场景：用户资料可能分散在 users（主表）、user_profiles_v2（新表）、legacy_user_data（老系统）三张表中，希望优先取 v2 表字段，没有则退到 legacy，最后 fallback 到主表。
错误写法：COALESCE((SELECT name FROM user_profiles_v2 WHERE id = u.id), (SELECT name FROM legacy_user_data WHERE id = u.id), u.name) —— 子查询性能差，且无法利用索引下推。
正确思路是先 LEFT JOIN 所有候选表，再用 COALESCE 择优取值：
SELECT u.id, COALESCE(p2.name, l.name, u.name) AS name, COALESCE(p2.email, l.email, u.email) AS email FROM users u LEFT JOIN user_profiles_v2 p2 ON u.id = p2.user_id LEFT JOIN legacy_user_data l ON u.id = l.user_id;
JOIN 顺序决定优先级，不是 COALESCE 参数顺序
COALESCE 的参数顺序只是最终取值的 fallback 顺序，真正决定“哪个表的数据更可能被命中”的是 LEFT JOIN 的执行顺序和关联条件是否匹配。如果 p2.user_id 上没索引，即使把它放在 COALESCE 第一位，也可能因 JOIN 失败而返回 NULL。
- 确保每个 LEFT JOIN 的 ON 条件字段都有索引（如
user_profiles_v2(user_id)） - 把最高优先级的表放在第一个
LEFT JOIN，不是为了COALESCE，而是为了让优化器更倾向使用它的驱动表路径 - 避免在 JOIN 条件中用函数（如
ON u.id = CAST(l.user_id AS BIGINT)），会跳过索引
NULL 值干扰时，COALESCE 不够用，得加 CASE
如果某张表的字段允许 NULL，但业务上 NULL 并不表示“无数据”，而是“明确未填写”，那 COALESCE 就会错误地跳过它去取下一个表的值。比如 user_profiles_v2.name 是 NULL，但你想保留这个 NULL，而不是用 legacy_user_data.name 覆盖它。
这时必须改用 CASE 显式控制逻辑：
COALESCE( CASE WHEN p2.name IS NOT NULL THEN p2.name END, CASE WHEN l.name IS NOT NULL AND l.source = 'trusted' THEN l.name END, u.name )
或者更清晰地拆开判断：
CASE WHEN p2.name IS NOT NULL THEN p2.name WHEN l.name IS NOT NULL AND l.is_valid = TRUE THEN l.name ELSE u.name END AS name
性能陷阱：多 LEFT JOIN 容易引发笛卡尔积或膨胀
当多个候选表对同一主表存在一对多关系时（比如一个用户有多个 profile 版本、多条 legacy 记录），LEFT JOIN 会导致中间结果集爆炸，COALESCE 也救不了——它只取第一行的字段，但重复行仍会拖慢整个查询。
解决方法不是减少 JOIN，而是提前聚合或限制关联数量：
- 用子查询或 CTE 预先取每个用户的最高优先级记录：
(SELECT ... FROM user_profiles_v2 WHERE user_id = u.id ORDER BY version DESC LIMIT 1) - 给 legacy 表加时间戳或状态过滤：
LEFT JOIN legacy_user_data l ON u.id = l.user_id AND l.updated_at = (SELECT MAX(updated_at) FROM legacy_user_data l2 WHERE l2.user_id = u.id) - 确认是否真的需要所有字段都走同一套优先级逻辑——有时邮箱和头像的来源策略不同，应分开处理
最常被忽略的是：JOIN 本身不保证顺序，数据库不会因为你在 COALESCE 里写了 p2 在前，就强制让 p2 的数据“覆盖”l 的数据；它只忠实地合并你提供的关联结果。所以优先级本质是建模出来的，不是语法糖喂出来的。
