left join + coalesce 是实现多表优先级兜底的标准方案：先对主表依次 left join 各候选表，再用 coalesce(t1.val, t2.val, t3.val) 从左到右取首个非 null 值，确保主表行不丢失、逻辑清晰、跨数据库兼容。
用 LEFT JOIN + COALESCE 实现优先级兜底
当需要从多个表中按「A 表优先，A 没有则用 B，B 也没有再用 C」这种逻辑取值时，LEFT JOIN 配合 COALESCE 是最直接、可读性最强的方式。它不依赖数据库特有语法，MySQL/PostgreSQL/SQL Server 都支持。
常见错误是试图用多个 INNER JOIN 或嵌套子查询强行“筛选最高优先级”，结果要么漏数据，要么重复或性能爆炸。
实操建议：
- 所有候选表都用
LEFT JOIN关联主表（不能用INNER JOIN，否则主表缺失匹配项的行会被过滤掉） - 在
SELECT中用COALESCE(t1.val, t2.val, t3.val)按顺序取第一个非 NULL 值 - 确保被
COALESCE的字段在语义上等价（比如都是价格、都是状态码），否则逻辑会错乱 - 给各关联字段加索引（如
ON t1.id = main.ref_id中的t1.id和main.ref_id）
用 ROW_NUMBER() + CTE 排序后取 Top 1（适合复杂优先级规则）
当优先级不是简单“表 A > 表 B > 表 C”，而是依赖字段值（比如 status = 'active' > status = 'pending' > status = 'archived'），或者要跨表统一排序时，ROW_NUMBER() 更灵活。
典型坑是忘记 PARTITION BY 导致全表只排一个序号，或 ORDER BY 里没处理 NULL 值导致优先级错位。
实操建议：
- 把所有候选数据 UNION ALL 到一个 CTE 中，增加一列
priority_rank显式表达优先级（例如 active → 1，pending → 2） - 在窗口函数中用
ROW_NUMBER() OVER (PARTITION BY main_id ORDER BY priority_rank) - 外层只取
rn = 1的记录，再和主表LEFT JOIN - 注意 UNION ALL 各子句字段类型和顺序必须严格一致，否则报错
UNION types text and integer cannot be matched
避免用 CASE WHEN ON 条件硬编码优先级
有人会写 ON main.id = t1.id OR (t1.id IS NULL AND main.id = t2.id) 这类条件，看似“先试 t1 再试 t2”，实际是错的：SQL 的 ON 条件不保证执行顺序，优化器可能重排，且 OR 容易让索引失效。
更隐蔽的问题是，这类写法会让 JOIN 变成笛卡尔积风险——尤其当某张表没有匹配时，OR 可能触发意外连接。
实操建议：
- 绝对不要在
ON里用OR跨表模拟优先级 - 如果真要用
CASE，只放在SELECT或子查询里，不参与连接逻辑 - 用
EXPLAIN看执行计划，确认没有出现type: ALL或rows异常放大
MySQL 8.0+ 可用 LATERAL（但慎用）
MySQL 8.0.14+ 支持 LATERAL，能实现类似“对每行主表，依次查 t1/t2/t3 直到有结果”的语义，看起来最贴近直觉。但它要求子查询必须相关（correlated），且目前优化器对 LATERAL 支持仍不成熟。
容易踩的坑是子查询里忘了加 WHERE 关联主表字段，导致变成无关联子查询，报错 Error 1248: Every derived table must have its own alias；或者性能比 COALESCE 方案差 3–5 倍。
实操建议：
- 仅当其他方案无法满足（比如优先级逻辑需调用存储函数）时才考虑
LATERAL - 子查询必须显式引用主表别名，例如
(SELECT * FROM t1 WHERE t1.ref_id = main.id LIMIT 1) AS x - 务必加
LIMIT 1，否则LATERAL可能返回多行破坏主表结构 - 上线前用真实数据量压测，对比
COALESCE版本的 QPS 和延迟
真正难的不是写出能跑的 SQL，而是当优先级规则随业务变化（比如新增一个“override”表）、或某张表数据质量下降（大量 NULL 或脏状态）时，你的 JOIN 是否还稳定输出预期结果。这时候，把优先级逻辑从 SQL 搬到应用层做 fallback，反而更可控。
