EAV模型如何提升性能

EAV（Entity–Attribute–Value，实体–属性–值）模型常用于属性高度动态、稀疏、Schema 不固定的场景（如电商商品、医疗档案、配置系统）。但它天然存在查询复杂、JOIN 多、聚合慢的问题。下面从「模型设计 → 存储 → 查询 → 架构」系统讲如何提升 EAV 性能。

一、模型层优化（先少写 EAV）

1. 热点属性“去 EAV 化”

• 将高频、固定、用于过滤/排序的字段抽成普通列
• 只把低频、动态、稀疏属性放 EAV

✅ 示例
商品表：

products(
  id,
  title,        -- 普通列
  price,        -- 普通列
  category_id   -- 普通列
)
product_attrs(  -- 真正的 EAV
  product_id,
  attr_id,
  value
)

2. 属性元数据规范化

• attr_id 用字典表，而不是字符串
• 避免 WHERE attr = 'color'（字符串比较慢）

attributes(id, name, type)

二、存储层优化（核心）

3. 垂直拆分 EAV 表

按 属性类型 拆分：

product_attrs_int
product_attrs_decimal
product_attrs_text

避免一行存多种类型导致索引失效。

4. 使用「宽表 + EAV 混合」

• 冷数据：EAV
• 热数据：定时物化成宽表

product_attr_snapshot (
  product_id,
  color,
  size,
  weight
)

5. JSON / 文档型存储（强烈推荐）

在 PostgreSQL / MySQL 8+：

attributes JSONB

• 建 GIN 索引
• 查询快、写入灵活

WHERE attributes @> '{"color":"red"}'

✅ 很多场景 JSON 比传统 EAV 快 10x+

三、查询层优化

6. 避免 N+1 查询

❌ 错误：

for product in products:
  select * from eav where product_id = ?

✅ 正确：

SELECT * FROM eav WHERE product_id IN (...)

7. 用 PIVOT / 条件聚合

SELECT
  product_id,
  MAX(CASE WHEN attr='color' THEN value END) AS color,
  MAX(CASE WHEN attr='size' THEN value END) AS size
FROM eav
GROUP BY product_id

8. 预聚合 / 物化视图

• 定时生成“属性宽表”
• 查询只读宽表

四、索引策略

9. 复合索引

(product_id, attr_id)
(attr_id, value)

10. 倒排索引（全文 / JSON）

• PostgreSQL GIN
• Elasticsearch

五、架构级方案（大规模）

11. EAV + 搜索引擎

• EAV 用于存储
• Elasticsearch / Solr 用于查询

流程：

写 → DB(EAV)
     → 同步 → ES
读 → ES

12. 列式存储（分析场景）

• ClickHouse
• DuckDB
• 适合“属性极多、读多写少”

六、什么时候不该用 EAV？

❌ 属性稳定
❌ 需要复杂事务
❌ 高频聚合

✅ 替代方案：

• JSON
• 宽表
• 多表继承

总结一句话

EAV 不是性能问题，而是“用错地方”的问题
高频属性列化，低频属性 EAV 或 JSON，查询走宽表 / 搜索引擎。

如果你有具体场景（MySQL / PG / 商品 / 医疗 / 配置），我可以给你直接可落地的表结构 + SQL。