MySQL+Laravel9：商品详情存JSON列还是一对多关联更高效？

我使用MySQL和Laravel 9，现有products表与details表，详情数据为数组对象格式，当前通过hasMany关联查询。每个商品至少包含20条详情记录，现面临选择：将详情存入products表的JSON列，还是保留可能达20亿行的details表、每次请求商品时查询所有详情行，想了解大数据场景下哪种方式性能更优。

详情数据示例 #

[
  {
    "name": "name",
    "data": {"color": "#000", "font": "sans"},
    "type": "type"
  },
  {
    "name": "title",
    "data": {"id": [1,2,3]},
    "type": "type"
  },
  ....
]

当前关联代码 #

public function details()
{
    return $this->hasMany(Detail::class);
}

一、查询性能对比 #

• 关联表方案：当details表达到20亿行时，即便给product_id建立了索引，单商品查询20条详情的开销也会显著上升——索引扫描范围大，磁盘IO压力高，高并发场景下数据库连接和查询队列极易被占满。如果没做预加载，Laravel的hasMany关联还会触发N+1查询问题，进一步放大性能损耗。
• JSON列方案：查询商品时直接从products表读取JSON字段，一次单表查询就能拿到所有详情，彻底避免跨表关联的开销。若经常需要查询详情里的特定字段，还能给JSON字段创建虚拟列+索引，大幅提升特定条件的查询效率。

二、写入/更新性能对比 #

• 关联表方案：新增一个商品需要插入1条主表记录+至少20条子表记录，20亿行的大表插入时，索引维护成本极高，写入速度会非常慢；更新某条详情时，即便有索引，大表的更新锁等待也会成为性能瓶颈。
• JSON列方案：新增/更新商品详情只需操作products表的一行数据，写入/更新成本极低，尤其是批量修改多个详情时，直接修改JSON内容即可，无需多次子表操作。但要注意控制单条JSON的大小，若超过1MB会导致行数据过大，影响磁盘IO和缓存效率。

三、维护成本与扩展性 #

• 关联表方案：20亿行的子表会让数据库备份、恢复、分区等运维操作的成本剧增；但后续新增详情字段时，只需修改子表结构，兼容性较好。
• JSON列方案：无需维护额外子表，结构更简洁；但JSON字段没有强Schema约束，容易出现数据格式不一致的问题，后续修改字段逻辑需要在应用层做兼容处理。

四、适用场景总结 #

• 优先选JSON列：如果查询以「获取商品全部详情」为主，很少单独查询某条详情或按详情字段过滤商品，且单条JSON数据大小可控（建议不超过500KB），大数据场景下JSON列的性能优势会非常明显。
• 保留关联表：如果需要频繁按详情的特定字段筛选商品（比如按data->color过滤），或者需要对详情做单独的增删改操作，且能通过分表（按product_id哈希分表）、分区等手段优化大表性能，关联表方案更合适。

内容的提问来源于stack exchange，提问作者farsheed ahmadian