电商如何用EAV模型

在电商系统中，EAV（Entity–Attribute–Value，实体–属性–值）模型常用于解决“商品属性高度灵活、品类差异巨大”的问题。下面从是什么、为什么用、怎么用、实际结构、优缺点与替代方案几个角度说明。

一、什么是 EAV 模型

传统表结构：

商品表：id, name, price, color, size, weight, brand...

问题：不同品类属性不同（手机有“内存”，衣服有“尺码”），字段会爆炸。

EAV 把数据拆成三张核心表：

• Entity（实体）：商品本身
• Attribute（属性）：颜色、尺寸、品牌等
• Value（值）：具体数值

二、电商为什么用 EAV

✅ 适用场景：

• 多品类商城（服装 / 3C / 美妆）
• 属性经常新增
• SKU 维度复杂

❌ 不适合：

• 属性固定的系统
• 高频聚合统计（性能差）

三、典型 EAV 表结构（电商示例）

1️⃣ 实体表（商品）

products
--------
id
name
category_id

2️⃣ 属性表

attributes
----------
id
name        -- 颜色、尺寸
type        -- string / int / enum

3️⃣ 值表

product_attributes
------------------
product_id
attribute_id
value

示例数据：

商品：iPhone 15
属性：颜色 → 黑色
属性：存储 → 256G

四、电商中的实际应用方式

✅ 1. 商品详情页

• 动态读取属性
• 不同品类展示不同字段

✅ 2. 筛选 & 搜索

WHERE attribute='品牌' AND value='Apple'

⚠️ 大型电商通常会：

• EAV + 宽表冗余
• ES / Solr 做搜索

✅ 3. SKU 维度

EAV 常配合：

SPU（标准产品）
SKU（库存单位）

SKU 级属性用 EAV 存储

五、Magento / Shopify 的做法

• Magento：经典 EAV（产品、客户都用）
• Shopify：内部 EAV + 外部 API 扁平化

六、EAV 的缺点与优化

❌ 问题：

• SQL 复杂（大量 JOIN）
• 查询慢
• 不好做报表

✅ 优化方案：

1. EAV + 冗余宽表
2. 热数据走缓存
3. 搜索走 Elasticsearch
4. 只把“灵活属性”放 EAV

七、什么时候不该用 EAV

✅ 更适合用：

• JSON 字段（MySQL / PG）
• 宽表 + 扩展字段
• 图数据库（复杂关系）

八、一句话总结

电商用 EAV，是为了用复杂度换灵活性，但生产中通常是
EAV + 冗余 + 搜索引擎 的混合架构。

如果你愿意，我可以：

• 画一张 EAV 电商结构图
• 给你一个 MySQL 完整示例
• 对比 EAV vs JSON 方案