PHP/MySQL：书籍多语言标题分栏存储还是单栏分隔存储？

核心问题结论 #

在10K+条目的规模下，方案A（多列存储）拉取空值的性能消耗远低于方案B（单列存储后PHP拆分），二者差异会比较明显。

性能差异分析 #

方案A的空值开销

MySQL对NULL值的存储和传输做了深度优化：

• InnoDB引擎中，可变长度字段的NULL值几乎不占用额外存储空间；固定长度字段的NULL仅通过位图标记，不会浪费实际数据空间。
• 传输层面，MySQL不会为NULL列传输无用数据，10K条数据的空列传输量甚至可能比方案B的单列更小——因为方案B的单列需要存储en:xxx;sp:xxx这类冗余的语言标识前缀，反而会增加单条数据的长度。

方案B的PHP拆分开销

方案B的性能瓶颈主要在应用层：

• 每条数据需要至少两次explode()调用（先按;拆分语言项，再按:拆分键值），还要循环构建语言-标题的映射数组，10K条数据的循环处理会带来明显的CPU开销。
• 如果标题中包含;或:这类分隔符，还需要额外做转义/处理逻辑，进一步增加复杂度和性能损耗；一旦存储格式出现错误（比如缺少数号、冒号），排查和修复成本极高。

方案优劣对比 #

方案A的优劣势

• 优势：
  • 支持精准的SQL搜索/过滤（比如直接WHERE title_en LIKE '%xxx%'），还能给单语言列加索引，大幅提升搜索性能；
  • 数据结构清晰，维护成本低，新增语言只需要加列（10K规模下完全可控）；
  • 无需应用层额外处理，直接读取即可使用。
• 劣势：
  • 表结构会有多个空列，但这只是视觉上的“不美观”，实际对性能和存储无显著影响；可以用空字符串替代NULL，避免NULL带来的判断逻辑。

方案B的优劣势

• 优势：仅有的优势是表结构简单（只有两列），但这个优势在实际场景中几乎可以忽略。
• 劣势：
  • 无法直接通过SQL针对某语言标题做过滤、排序或统计，必须全量拉取后在PHP中处理，数据量越大开销越高；
  • 扩展性差，新增语言需要修改应用层的拆分逻辑，且存储格式容易出现不一致；
  • 数据可读性差，排查问题时无法直接通过SQL查看某语言的标题内容。

更优的规范化方案 #

如果追求完全符合数据库设计规范，建议使用关联表存储方案：

1. 主表books：存储书籍核心信息（id, publish_date, ...）
2. 关联表book_titles：字段为book_id（关联主表ID）、lang_code（语言标识，如en/sp）、title（对应语言的标题）

这种方案的好处：

• 无空值，存储高效；
• 扩展性极强，新增语言只需在关联表中插入数据，无需修改表结构；
• 支持灵活的SQL查询（比如SELECT title FROM book_titles WHERE book_id = 1 AND lang_code = 'ja'）；
• 10K条主数据对应的关联表数据量完全在MySQL的处理能力范围内，性能无压力。

内容的提问来源于stack exchange，提问作者Christopher B