MySQL如何正确设计产品变体（Product Variation）表结构

你这套设计思路存在比较明显的结构缺陷，后续做库存、价格、SKU管理的时候会踩很多坑，我给你理下问题和成熟的落地方案：

• 违反数据库设计第一范式：产品表中Product Size、Product Color字段用逗号拼接存储多个ID，后续做筛选、关联库存、销售统计时必须额外做字符串拆分，查询性能极差，还很容易出现数据不一致——比如删除了某个已下架的尺寸，忘了同步更新产品表里的拼接字符串，就会出现脏数据。
• 属性复用性差：颜色、尺寸这类是全平台商品通用的属性，你现在每个商品单独存对应的颜色、尺寸记录，会产生大量重复冗余数据，后续要统一改个属性值名称（比如把“XXXL”改成“3XL”）得全表扫一遍改所有关联商品的记录。
• 无法支撑变体独立属性：不同变体（比如M码白色夹克、XXXL黑色夹克）的SKU编码、售价、库存、专属展示图、重量可能都不一样，你现在的结构根本没有存储这些信息的位置，业务根本跑不起来。

这套结构是电商行业通用的产品变体设计方案，扩展性强，查询效率高：

1. 产品主表（products） #

只存所有变体共有的公共基础信息，不要存任何拼接的属性ID

| id | product_name | product_description | base_price | created_at |
|----|--------------|---------------------|------------|------------|
| 1  | Jacket       | Jacket.....         | 199        | 2024-01-01 |

2. 属性名表（attributes） #

存所有变体维度的属性名称，全平台通用可复用，不用为每个商品单独建属性表

| id | attribute_name |
|----|----------------|
| 1  | 颜色           |
| 2  | 尺寸           |

3. 属性值表（attribute_values） #

存每个属性对应的可选值，全平台通用

| id | attribute_id | value_name |
|----|--------------|------------|
| 1  | 1            | 白色       |
| 2  | 1            | 黑色       |
| 3  | 2            | M          |
| 4  | 2            | XXXL       |

4. 产品-属性关联表（product_attributes） #

绑定当前商品支持哪些变体维度，比如夹克支持颜色、尺寸两个维度，裤子可能多一个裤长维度

| id | product_id | attribute_id |
|----|------------|--------------|
| 1  | 1          | 1            |
| 2  | 1          | 2            |

5. 产品变体表（product_variants） #

核心表，每一条记录对应一个具体可售的SKU，存这个SKU独有的业务信息

| id | product_id | sku    | price | stock | weight | variant_image |
|----|------------|--------|-------|-------|--------|---------------|
| 1  | 1          | J001   | 199   | 20    | 0.5kg  | white_m.jpg   |
| 2  | 1          | J002   | 199   | 15    | 0.5kg  | black_m.jpg   |
| 3  | 1          | J003   | 219   | 8     | 0.7kg  | white_xxxl.jpg|
| 4  | 1          | J004   | 219   | 5     | 0.7kg  | black_xxxl.jpg|

6. 变体-属性值关联表（variant_attribute_values） #

绑定每个具体SKU对应的属性值组合

| id | variant_id | attribute_value_id |
|----|------------|--------------------|
| 1  | 1          | 1（白色）          |
| 2  | 1          | 3（M码）           |
| 3  | 2          | 2（黑色）          |
| 4  | 2          | 3（M码）           |
| 5  | 3          | 1（白色）          |
| 6  | 3          | 4（XXXL码）        |
| 7  | 4          | 2（黑色）          |
| 8  | 4          | 4（XXXL码）        |

• 如果你的业务非常简单，永远只做颜色、尺寸两个变体维度，完全可以简化结构：不用单独建属性名、属性值表，直接在产品变体表加color_id、size_id字段，开发成本更低，查询更直接。
• 新增商品变体时，一定要做属性组合的去重校验，避免出现同属性组合的重复SKU。
• 前台做商品筛选时，直接关联变体属性值表查询即可，所有关联字段都可以加索引，查询速度比拆分字符串快几个量级。
• 这套结构扩展性很强，后续要加新的变体维度（比如材质、版型、容量），不需要修改现有表结构，只需要在属性名表新增对应记录即可。

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