EAV模型对索引有什么要求

EAV（Entity-Attribute-Value，实体-属性-值）模型是一种用于应对高度动态、稀疏属性结构的数据建模方式（典型场景：商品属性、医疗病历、自定义表单）。

由于它的结构特点，对索引设计有非常特殊的要求，核心目标是：避免全表扫描、支持按属性筛选、支持聚合分析。

一、EAV 模型的结构特点（决定索引要求）

典型 EAV 表结构：

entity_id | attribute_id | value

或

entity_id | attribute_id | value_string | value_number | value_datetime

特点：

• 行数极多（属性被“竖表化”）
• 一个实体由多行表示
• 查询通常是“找具备某属性的某个值”

二、EAV 对索引的核心要求

1️⃣ 必须有 (attribute_id, value) 组合索引

这是最重要、最基础的索引。

CREATE INDEX idx_attr_value
ON eav (attribute_id, value);

✅ 用途：

• 查询“某个属性 = 某个值”
• 避免扫描所有属性行

SELECT entity_id
FROM eav
WHERE attribute_id = 101
  AND value = 'red';

⚠️ 单独索引 attribute_id 或 value 都不够。

2️⃣ 必须包含 entity_id（顺序很关键）

如果查询是：

• 按属性筛选
• 再关联实体主表

推荐：

(attribute_id, value, entity_id)

✅ 好处：

• 覆盖索引
• 避免回表

3️⃣ 按值类型分列 / 分表时，索引要对应类型

如果 EAV 拆成：

eav_string
eav_int
eav_date

那么每个表都需要：

(attribute_id, value)

❌ 不要在一个 value 列里混类型（索引效率极差）

4️⃣ 实体级索引仍然需要（很多人忽略）

EAV 表本身只是“属性附件”，实体主表必须有：

entity(id PK)
entity(type, status, created_at)

并建索引：

(type, status)
(created_at)

否则：

“查某类实体 + 某属性” 依然慢

5️⃣ 多属性组合查询（EAV 最痛点）

例如：

• 颜色 = red
• 尺寸 = L

方案 A：索引 + 应用层交集（最常见）

SELECT entity_id FROM eav WHERE attribute_id=101 AND value='red';
SELECT entity_id FROM eav WHERE attribute_id=102 AND value='L';

在代码中取交集。

✅ 简单
❌ 属性多时性能下降

方案 B：物化视图 / 宽表（推荐）

entity_id | color | size | price

对常用查询建索引：

(color, size)

✅ 查询极快
❌ 牺牲灵活性

方案 C：数据库特定能力

• PostgreSQL：JSONB + GIN
• MySQL 8：函数索引 / 生成列
• Elasticsearch：天然适合 EAV

6️⃣ 避免的索引误区

❌ 只在 entity_id 上建索引
❌ 在 value 上建单列索引
❌ 用 LIKE 查 EAV（无法走索引）
❌ 期望 EAV 像宽表一样快

三、不同数据库的 EAV 索引建议

四、一句话总结

EAV 模型对索引的要求是：以“属性 + 值”为核心建立组合索引，并配合实体主表索引和宽表/搜索引擎来缓解多属性查询性能问题。

如果你愿意，我可以：

• 给你一个 EAV vs 宽表索引对比
• 或针对 MySQL / PG / ES 给具体建表 + 索引方案