应使用独立translation表存储多语言内容，通过locale、resource_type、resource_id、field_name和content字段实现灵活扩展与精准查询，避免主表膨胀和结构僵化。
用单独的翻译表 + 语言标识字段，别硬塞进主表
把中文、英文、日文等字段全加到 product 表里（比如 name_zh、name_en、name_ja）看起来省事，实际一加新语言就得改表结构，还容易让主表膨胀。正确做法是拆出一张 translation 表，存语言代码、所属实体类型、实体 ID、字段名、翻译值。
示例结构：
CREATE TABLE translation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, locale CHAR(5) NOT NULL COMMENT 'en_US, zh_CN, ja_JP', resource_type VARCHAR(32) NOT NULL COMMENT 'product, category, article', resource_id BIGINT NOT NULL, field_name VARCHAR(64) NOT NULL COMMENT 'title, description, slug', content TEXT NOT NULL, UNIQUE KEY uk_locale_resource (locale, resource_type, resource_id, field_name) );
-
locale用CHAR(5)足够（如zh-CN或en-US），别用VARCHAR(16)浪费索引空间 -
resource_type和resource_id组合模拟多态关联，比每种实体建一张翻译表更灵活 - 联合唯一索引
uk_locale_resource防止重复翻译，也加速按语言查某条记录的某个字段
查询时用 LEFT JOIN + COALESCE 优雅 fallback
用户请求 zh-TW，但数据库只存了 zh-CN 和 en-US，你不能返回空——得自动降级到 zh-CN，再不行才用 en-US，最后兜底主表原始字段（比如 product.name）。靠写死多个 LEFT JOIN 太难维护，推荐在应用层拼 SQL 或用 MySQL 8.0+ 的 JSON_TABLE 配合预定义 fallback 链，但最稳的仍是服务端控制逻辑。
简单场景下可这样写（假设只 fallback 一级）：
基于PHP+MYSQL开发，除了网上书店必备的商品管理、配送支付管理、订单管理、会员分组、会员管理、查询统计和多项商品促销功能，还具有完整的文章、图文、下载、单页、广告发布等网站内容管理功能。系统具有静态HTML生成、UTF-8多语言支持、可视化模版引擎等技术特点，支持多频道调用不同模版和任意设置频道首页，适合建立各种规模的网上书店。系统具有以下主要功能模块： 网站参数设置 - 对网站的一些参数进
SELECT p.id, COALESCE(t1.content, t2.content, p.name) AS name FROM product p LEFT JOIN translation t1 ON t1.resource_type = 'product' AND t1.resource_id = p.id AND t1.field_name = 'name' AND t1.locale = 'zh-TW' LEFT JOIN translation t2 ON t2.resource_type = 'product' AND t2.resource_id = p.id AND t2.field_name = 'name' AND t2.locale = 'zh-CN';
- 别依赖 MySQL 自动做语言模糊匹配（比如把
zh-TW当成zh查），它不支持 locale 层级 fallback -
COALESCE顺序就是 fallback 优先级，越靠前越优先 - 如果 fallback 链长（如
de-AT → de-DE → de → en），JOIN 太多影响性能，建议在应用层查一次所有可能 locale 的翻译，再内存合并
避免用 JSON 字段存多语言内容
有人图快，直接在 product 表加个 name_i18n JSON 字段，存 {"en": "Apple", "zh": "苹果"}。这会导致几个硬伤：
- 无法为单个语言值建索引，
WHERE JSON_EXTRACT(name_i18n, '$.zh') = '苹果'全表扫描 - 更新某个语言时要读-改-写整个 JSON，高并发下易丢数据或触发锁等待
- 没法约束
locale格式，容易存入zh_cn、ZH、Chinese等不一致值，后续查询和缓存都混乱 - 备份、同步、审计时 JSON 字段内容不可见、不可搜索
注意字符集与排序规则的实际影响
即使用了 utf8mb4，不同语言对排序、大小写、比较的要求差异很大。比如德语中 ä 在某些 collation 下等价于 ae，法语中 é 和 e 可能被当作相同字符比较。
- 翻译表的
content字段必须用utf8mb4_unicode_ci或更细粒度的 collation（如utf8mb4_de_pb_0900_as_cs），不能用默认的utf8mb4_0900_ai_ci——它对重音符号不敏感，搜cafe会命中café - 如果业务需要按翻译内容模糊搜索（如后台搜“苹果”找所有语言含该词的商品），建议额外建一个带语言标识的全文索引表，或用 Elasticsearch 同步翻译字段
- 前端传来的
Accept-Language值（如zh-CN,zh;q=0.9,en;q=0.8）要解析出有效 locale 列表，并标准化为小写、短横线分隔格式（zh-CN），再查库；别直接拿原始字符串去匹配
多语言系统最难的不是存和取，而是 locale 的标准化、fallback 的策略一致性、以及翻译内容变更后缓存如何精准失效——这些在数据库层只能打基础，真正的水深在应用与缓存协同上。
