视图不能接收语言参数，必须用LEFT JOIN暴露多语言字段：因SQL标准不支持运行时变量，需为每种语言显式LEFT JOIN翻译表并固定lang值，字段命名带后缀（如name_zh），主键+语言列须建联合索引，避免INNER JOIN导致数据丢失或JSON方案引发性能与维护问题。
视图不能接收语言参数，必须用LEFT JOIN暴露多语言字段
SQL标准不支持视图定义中使用运行时变量（如@lang或$1），所以写WHERE lang = @lang会直接报错或被忽略。所谓“多语言视图”，本质是把语言选择逻辑交给查询层，视图只负责把各语言字段并列“摊开”。
常见错误是用INNER JOIN关联翻译表——一旦某条记录缺中文翻译，整行就从结果里消失。必须用LEFT JOIN保证主表数据始终可见。
- 每个语言建一个独立
LEFT JOIN，条件固定写死语言值（如AND t_zh.lang = 'zh'） - 字段命名带后缀，如
title_zh、title_en、desc_ja - 主键+语言列必须有联合索引，否则每次查不同语言都会全表扫描翻译表
创建视图时要为每种语言显式JOIN翻译表
比如业务稳定支持中/英/日三语，视图定义就得写三个LEFT JOIN，不能靠CASE WHEN或JSON路径动态提取——那会失去索引能力，且无法在视图里做语言fallback。
示例结构：
CREATE VIEW product_i18n_view AS SELECT p.id, p.sku, t_zh.name AS name_zh, t_zh.description AS desc_zh, t_en.name AS name_en, t_en.description AS desc_en, t_ja.name AS name_ja, t_ja.description AS desc_ja FROM products p LEFT JOIN product_translations t_zh ON p.id = t_zh.product_id AND t_zh.lang = 'zh' LEFT JOIN product_translations t_en ON p.id = t_en.product_id AND t_en.lang = 'en' LEFT JOIN product_translations t_ja ON p.id = t_ja.product_id AND t_ja.lang = 'ja';
后续查中文就SELECT id, name_zh, desc_zh FROM product_i18n_view，应用层按用户Accept-Language选字段，不用改SQL。
JSON字段方案在视图里能用但不推荐
如果翻译存在JSON字段（如name_json），MySQL 8.0+可用name_json->>"$.zh"提取字符串，但要注意：->>返回的是普通字符串，->返回JSON类型需CAST；两者都无法走索引，查得越频繁，性能越差。
更关键的是：JSON字段会让视图失去类型提示和IDE自动补全能力，调试和维护成本陡增。
- 仅当语言种类极不稳定（每月新增）、且查询量极低时才考虑JSON方案
- 必须加生成列+索引才能勉强缓解性能问题，但增加维护负担
- 绝大多数业务场景下，显式字段 + LEFT JOIN 更可靠、更易监控、更利于慢查定位
容易被忽略的索引和NULL处理细节
翻译表没索引是最常见的线上性能坑——哪怕只有几千条翻译，查一次英文再查一次中文，两次全表扫描叠加可能拖垮整个接口。
联合索引必须覆盖外键+语言列，例如INDEX idx_product_lang (product_id, lang)，顺序不能反。
另外，COALESCE(t_zh.title, t_en.title)看似方便，实则让所有JOIN失效——数据库无法判断哪个分支实际被用到，优化器大概率放弃使用索引。真要fallback，应该在应用层判断字段是否为NULL后再决定取哪个值。
