SELECT子查询不适合多语言切换，会导致索引失效、性能下降、维护困难；正确做法是用LEFT JOIN摊开字段或聚合CASE，语言路由应交由应用层处理。

SELECT 列表里的子查询不是为多语言切换设计的，硬塞进去只会让索引失效、性能线性下降、维护成本飙升。

在SEO发布前，从路由清单生成XML网站地图和robots.txt

当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。

下载

为什么不能在 SELECT 子查询里切语言

• Subquery returns more than 1 row 错误频发：稍不注意漏写 WHERE t_zh.product_id = p.id AND t_zh.lang = 'zh'，子查询就返回多行
• 索引完全失效：哪怕翻译表有 (product_id, lang) 联合索引，子查询里写死 t_en.lang = 'en' 或用 CASE @lang，优化器无法下推条件，只能全表扫描
• 每加一种语言就得改一次子查询结构，没法动态适配 @lang 变量
• MySQL/PostgreSQL 对相关子查询的执行计划不友好，数据量一过十万，响应直接卡顿

视图里该怎么做才对

• 视图必须用 LEFT JOIN 关联每种语言的翻译表，把字段“摊开”成 name_zh、name_en、description_ja 这类带后缀的列
• 所有 lang 条件必须写在 ON 子句里，绝不能挪到 WHERE —— 否则等效于 INNER JOIN，缺翻译的主记录直接消失
• 必须建联合索引：CREATE INDEX idx_pt_pid_lang ON product_translations (product_id, lang_code);
• 应用层查中文就选 name_zh，查英文就选 name_en，SQL 不动，逻辑前移

语言太多（比如 >5 种）怎么办

• 放弃视图里堆 LEFT JOIN，改用聚合方式收口：
  SELECT p.id, MAX(CASE WHEN pt.lang_code = 'zh' THEN pt.name END) AS name_zh, MAX(CASE WHEN pt.lang_code = 'en' THEN pt.name END) AS name_en FROM products p LEFT JOIN product_translations pt ON p.id = pt.product_id GROUP BY p.id;
• 这种写法只扫一遍翻译表，但要求 product_id 和 lang_code 组合唯一，否则 MAX() 可能取错值
• 如果业务需要 fallback（如 zh 缺失时自动取 en），别在视图里写 COALESCE(name_zh, name_en) —— 它会让上面的 MAX(CASE...) 索引失效，fallback 逻辑应交给应用层或存储过程处理

真正难的不是怎么写 SQL，而是接受「SQL 层不适合做运行时语言路由」这个事实。视图只管结构拼接，语言选择交给上层，索引才能稳，扩展才有底。