如何优化EAV模型

EAV（Entity-Attribute-Value，实体-属性-值）模型常用于属性高度动态、稀疏、模式不稳定的场景（如电商商品属性、医疗病历、配置系统）。但它的天然缺陷是查询复杂、性能差、类型不安全、JOIN 爆炸。

下面从设计、存储、查询、架构四个层面系统讲“如何优化 EAV”。

一、设计层优化（先少写 EAV）

1. 区分「稳定字段」和「动态字段」

不要所有字段都进 EAV

• 高频、固定字段 → 普通表列
• 低频、稀疏、动态字段 → EAV

✅ 示例：

用户表：id, name, email（固定）
用户扩展属性：language, theme（EAV）

2. 属性元数据表（必须）

EAV 一定要配合：

attribute (
  id,
  name,
  data_type,
  entity_type,
  is_required,
  default_value
)

作用：

• 约束值类型
• 避免“脏属性”
• 支持 UI 动态渲染

3. 按实体类型分表（EAV 分片）

不要一个 EAV 表存所有实体

product_attribute_value
user_attribute_value
order_attribute_value

✅ 减少行数
✅ 提高索引效率

二、存储层优化（性能关键）

4. 值类型拆分（避免万能 VARCHAR）

❌ 反例：

value VARCHAR(255)

✅ 正例：

value_int
value_decimal
value_datetime
value_text

或者：

value_json  -- PostgreSQL / MySQL 8

5. 使用 JSON / 半结构化存储（强烈推荐）

现代数据库下，EAV 的“最优替代”：

PostgreSQL

attributes JSONB

加上：

GIN INDEX

MySQL 8

attributes JSON

✅ 优点：

• 少 JOIN
• 查询快
• 模式灵活

6. 物化视图 / 宽表同步

热数据从 EAV 同步到宽表：

EAV（写）
→ 定时/CDC
→ flat_table（读）

常用于：

• 报表
• 搜索
• 分析

三、查询层优化

7. 避免“透视查询”在应用层做

❌ 慢：

JOIN 几十次

✅ 优化方式：

• 用 GROUP BY + CASE
• 用 JSON 聚合

PostgreSQL 示例：

SELECT
  entity_id,
  jsonb_object_agg(attr_name, value) AS attrs
FROM eav
GROUP BY entity_id;

8. 只索引“常用属性”

不要全属性建索引

✅ 只索引：

• 高频过滤
• 排序字段

四、架构层优化（终极方案）

9. EAV + 搜索引擎

EAV 不适合搜索

✅ 同步到：

• Elasticsearch
• OpenSearch

结构：

{
  "id": 1,
  "name": "手机",
  "attrs": {
    "color": "black",
    "ram": "8G"
  }
}

10. CQRS（读写分离）

• 写：EAV / JSON
• 读：宽表 / 缓存 / ES

五、什么时候不该用 EAV？

❌ 属性数量稳定
❌ 查询频繁
❌ 强类型要求
✅ 直接用表列或 JSON

总结一句话

EAV 不是用来“替代表”，而是用来“补充表”的。

如果你愿意，可以：

• 给我你的业务场景（电商 / 医疗 / 配置）
• 或现有 EAV 表结构
  我可以直接帮你重构成最优方案。