LEFT JOIN 比 INNER JOIN 更适合默认语言降级，因其能保留主表所有记录，配合 COALESCE 实现回退逻辑；INNER JOIN 会丢弃无目标语言翻译的行，导致数据丢失。
为什么 LEFT JOIN 比 INNER JOIN 更适合默认语言降级？
因为要确保即使用户指定语言（如 'zh-CN'）没有对应翻译，也能回退到默认语言（如 'en-US'）的值。用 INNER JOIN 会直接丢掉缺失翻译的记录，而 LEFT JOIN 能保留主表数据，并通过 COALESCE() 补上备用值。
常见错误是把两个语言表都用 INNER JOIN 连接，结果某条内容在 'zh-CN' 中没录入时整行消失——这不是降级，是丢数据。
- 主表（如
messages）必须作为FROM的基础，不能放在子查询里当驱动表 - 默认语言表（
translations AS t_default）应与主表严格ON匹配，不加额外过滤条件 - 目标语言表（
translations AS t_target）的JOIN条件中必须包含语言筛选，但要用LEFT JOIN保证不中断主表关联
COALESCE(t_target.text, t_default.text) 的执行顺序和陷阱
这个表达式本身没问题，但容易忽略底层数据一致性问题：如果 t_target.text 是 NULL（比如字段允许 NULL 且未填值），它会正确 fallback；但如果该字段被设为 ''（空字符串），COALESCE 不会跳过它——空字符串不是 NULL，所以会原样显示，造成“有翻译但显示为空”的假象。
使用场景中，建议统一约定：缺失翻译时字段存 NULL，而非空字符串。若无法控制写入逻辑，得改用 NULLIF(t_target.text, '') 预处理：
COALESCE(NULLIF(t_target.text, ''), t_default.text)
-
COALESCE只按顺序判断是否为NULL，不识别语义上的“无效值” - 数据库对空字符串的索引效率通常低于
NULL，尤其在WHERE或JOIN条件中参与匹配时 - 若默认语言表也存在空字符串，同样需要嵌套
NULLIF，否则降级链断裂
如何避免子查询导致的性能坍塌？
有人倾向用子查询实现降级，例如在 SELECT 中写：(SELECT text FROM translations ... WHERE lang = 'zh-CN' LIMIT 1)。这种写法在小表上看似简洁，但每行都会触发一次独立查询，数据量稍大（比如 >1k 行）就会明显变慢，且无法利用联合索引加速。
真正高效的写法是单次双 LEFT JOIN + COALESCE，前提是两张翻译表都有复合索引：
CREATE INDEX idx_translations_msg_lang ON translations (message_id, lang);
- 没有这个索引时，
JOIN会走全表扫描，比子查询还慢 - 如果
lang值分布极不均匀（比如 95% 是'en-US'），考虑加WHERE lang IN ('zh-CN', 'en-US')配合索引覆盖 - PostgreSQL 用户注意：
COALESCE在某些版本中可能阻止索引下推，可改用CASE WHEN t_target.text IS NOT NULL THEN t_target.text ELSE t_default.text END测试对比
多层级降级（如 zh-CN → zh → en-US）怎么写才不爆炸？
三层 LEFT JOIN 是可行的，但别硬套四层以上——可读性和维护性断崖下跌，且优化器容易放弃使用索引。更稳妥的做法是把降级逻辑收口到一张“语言优先级映射表”，再用 LATERAL（PostgreSQL）或 APPLY（SQL Server）关联。
但绝大多数系统用不到三层以上。真遇到 zh-CN → zh → en-US 场景，优先检查是否能把 zh 级别翻译补全，而不是靠 SQL 层叠。SQL 不是翻译管理工具。
- 如果坚持用纯 SQL 实现三级降级，第三张表的
JOIN条件必须基于前一级未命中（即t_target.text IS NULL AND t_fallback.text IS NULL），否则会产生笛卡尔积 - MySQL 8.0+ 支持
LATERAL，但语法比 PostgreSQL 更受限，需确认版本 - 真正难的不是写出来，是让 DBA 接受这套逻辑进生产——他们更希望你把降级规则固化在应用层缓存里
