核心思路是用 LEFT JOIN + COALESCE 实现语言自动 fallback：优先取目标语言，缺失则回退默认语言；需避免 INNER JOIN 丢记录、硬编码 lang_code、WHERE 中直接过滤翻译字段导致索引失效等问题。
用 LEFT JOIN 实现多语言字段的动态 fallback
核心思路不是“切换语言”，而是让查询自动优先取目标语言、缺则回退到默认语言。直接 JOIN 多语言表容易丢记录（比如某产品没配英文描述），必须用 LEFT JOIN + COALESCE 组合。
- 假设主表
products(id, name_default, desc_default)存默认中文，翻译表product_translations(product_id, lang_code, name, description) - 查英文界面时，写
COALESCE(t_en.name, p.name_default)，而非t_en.name—— 否则没配英文的产品会显示NULL - 别在视图里硬编码
lang_code = 'en'，应通过参数化视图（如 PostgreSQL 的pg_catalog.current_setting('app.lang')）或应用层传入变量
PostgreSQL 中用 current_setting 做运行时语言上下文
MySQL 和 SQL Server 没原生会话级变量支持，PostgreSQL 可以用 current_setting() 动态读取客户端设置的语言，避免每次查询都传参。
- 应用连接后先执行
SET app.lang = 'ja';（需提前ALTER DATABASE ... SET app.lang = 'zh';设默认值） - 视图中写：
COALESCE((SELECT name FROM product_translations t WHERE t.product_id = p.id AND t.lang_code = current_setting('app.lang', true)), p.name_default) - 注意
current_setting(..., true)的第二个参数设为true，否则找不到变量时抛错，不是返回NULL
MySQL 8.0+ 替代方案：用 JSON 列存多语言字段
如果无法改表结构、又不想维护翻译表，MySQL 8.0+ 的 JSON 类型可把多语言文本扁平化存在一行里，用 JSON_EXTRACT + IFNULL fallback。
- 字段定义：
name_i18n JSON COMMENT '{"zh":"手机","en":"Smartphone","ja":"スマートフォン"}' - 查询写法：
IFNULL(JSON_UNQUOTE(JSON_EXTRACT(name_i18n, CONCAT('$.', @lang))), name_default)，其中@lang是用户语言变量 - 缺点：无法对 JSON 内部字段建索引，
LIKE模糊搜索低效；更新单个语言项需读-改-写整段 JSON
WHERE 条件里语言字段不能走索引的坑
很多人想按翻译内容搜索，比如 “找所有英文名含 ‘pro’ 的产品”，直接写 WHERE t_en.name LIKE '%pro%' 会导致全表扫描——因为 t_en 是 LEFT JOIN 的结果，优化器无法下推条件。
- 正确做法：把语言过滤提到子查询或 CTE 里，例如用
(SELECT name FROM product_translations WHERE product_id = p.id AND lang_code = 'en') AS en_name，再在外部WHERE en_name LIKE '%pro%' - 更稳妥的是单独建带语言前缀的冗余字段（如
name_en），加索引，适合搜索频繁但翻译更新少的场景 - 别依赖视图定义里的
WHERE过滤语言字段，视图只是封装逻辑，不改变执行计划
多语言视图真正的复杂点不在写法，而在缓存策略和数据一致性：应用层缓存 key 要包含语言维度，数据库物化视图（如 PostgreSQL 的 REFRESH MATERIALIZED VIEW CONCURRENTLY）不支持动态语言参数，得靠应用自己控制刷新边界。
