应采用单独语言表+外键关联（如product_i18n），统一locale格式为小写短横线（如'zh-cn'），使用utf8mb4_0900_as_cs或_ai_ci校对集，LEFT JOIN查询并由应用层处理fallback，缓存key须包含locale。
用单独语言表 + 外键关联，别往主表加一堆 language\_zh、language\_en 字段
主表硬塞多语言字段看着省事，实际查一次要读所有语言列，加个新语言就得 ALTER TABLE，索引也难建。正确做法是拆出 product_i18n 表，字段为 product_id、locale、title、description，联合主键设为 (product_id, locale)。
常见错误：把 locale 当成普通字符串存 'zh-CN' 或 'en_US'，结果排序、查询时大小写/下划线不一致导致漏数据。统一用小写加短横线格式，如 'zh-cn'、'en-us'，并在应用层校验。
- 查询某商品英文标题：
SELECT title FROM product_i18n WHERE product_id = 123 AND locale = 'en-us' - 插入前先
INSERT IGNORE或用ON DUPLICATE KEY UPDATE避免重复 - 给
(product_id, locale)加唯一索引，否则同一商品同一语言可能存多条
MySQL 5.7+ 必须用 utf8mb4，且 collation 要选 _0900_as_cs 或 _0900_ai_ci
utf8 在 MySQL 里实际是 utf8mb3，不支持 emoji 和部分生僻汉字；utf8mb4 才是真·UTF-8。但光改字符集不够——不同语言的排序和比较行为差异大，比如德语 ß 等价于 ss，法语重音字母要区分大小写。
容易踩的坑：utf8mb4_general_ci 已废弃，且对某些字符比较不严谨；utf8mb4_unicode_ci 在 8.0 后也被标记为 legacy。生产环境优先选 utf8mb4_0900_as_cs（大小写敏感、重音敏感）或 utf8mb4_0900_ai_ci（不区分大小写和重音），根据业务是否需要严格匹配来定。
- 建表时显式指定：
CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs - 已有表修改需连字段一起改：
ALTER TABLE product_i18n CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs - 连接层也要设对，比如 JDBC URL 加
?characterEncoding=utf8mb4
查多语言数据时，LEFT JOIN 比子查询快，但得小心 NULL 值处理
想查商品列表同时带当前语言标题，很多人写 (SELECT title FROM product_i18n WHERE product_id = p.id AND locale = 'zh-cn') 这种相关子查询——每行都触发一次独立查询，数据一多就卡死。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
正确姿势是 LEFT JOIN，但要注意：如果某商品没有对应语言记录，title 是 NULL，前端直接渲染会出空格或报错。不能依赖数据库 fallback 到默认语言，这事得在应用层控制。
- JOIN 写法示例：
SELECT p.id, i.title, i.description FROM product p LEFT JOIN product_i18n i ON p.id = i.product_id AND i.locale = 'zh-cn' - 避免
INNER JOIN，否则没翻译的商品直接被过滤掉 - 如果必须 fallback，默认语言查完再补一次 JOIN，或用
COALESCE(i.title, i2.title)（i2 是默认语言 alias），但注意性能损耗
“默认语言”不是配置项，是业务逻辑的一部分，得在代码里明确判定
有人在系统设置里配个 default_locale = 'zh-cn'，以为所有没翻译的地方自动走它——这会让 SQL 变复杂、缓存难做、审计困难。默认语言其实是读取逻辑的兜底策略，不是存储规则。
真实场景中，“用户没选语言时用哪个”、“后台编辑时显示哪个”、“导出报表用哪个”，三者很可能不同。把这些判断放在 DAO 层或 service 层，比塞进 SQL 或配置更可控。
- 不要在 INSERT 时自动复制默认语言内容到其他 locale 字段
- 不要在 SELECT 里用
CASE WHEN locale = 'zh-cn' THEN ... ELSE (SELECT ...)做 fallback - 缓存 key 要包含 locale，别让中英文响应混在一个 key 下
最麻烦的点其实不在数据库设计，而在应用层如何把「请求语言」、「编辑语言」、「回退语言」这三个概念理清楚、传对、不混淆。字段结构再漂亮，上游传错一个 locale，后面全白搭。
