EAV模型索引如何建

EAV（Entity-Attribute-Value，实体-属性-值）模型因为“宽表变窄表、行存属性”，在传统关系型数据库里索引设计非常关键，否则查询会全表扫描、性能崩。下面按“原则 → 常见索引 → 查询模式对应建法 → 实战示例”系统讲。

一、EAV 模型典型表结构

entity_id   BIGINT
attribute_id INT
value       VARCHAR / TEXT / NUMERIC

常配合：

• entities 表（实体主表）
• attributes 表（属性元数据）

二、EAV 索引设计核心原则

1. 避免对 value 单独建索引（除非类型固定）
2. 优先组合索引，而不是单列索引
3. 索引顺序 = 查询过滤顺序
4. 按属性类型分表 / 分区，比硬建索引更有效
5. 能不 EAV 就不 EAV（能 JSON 就 JSON）

三、最常用索引方案（必建）

✅ 1. 核心组合索引（最重要）

CREATE INDEX idx_eav_ea ON eav(entity_id, attribute_id);

✅ 适用：

• 查某实体所有属性
• 查某实体某属性

✅ 2. 按属性查值（Pivot 查询）

CREATE INDEX idx_eav_ae ON eav(attribute_id, value);

✅ 适用：

WHERE attribute_id = 10 AND value = 'VIP'

⚠️ 如果 value 是文本且很长：

• 用前缀索引

CREATE INDEX idx_eav_ae_pref ON eav(attribute_id, value(50));

✅ 3. 数值型属性（价格、年龄等）

CREATE INDEX idx_eav_num ON eav(attribute_id, CAST(value AS NUMERIC));

或 分表：

eav_int
eav_decimal
eav_text

四、典型查询 & 索引对应

场景 1：查用户所有属性

WHERE entity_id = 123

✅ 索引：(entity_id)

场景 2：查“状态=活跃”的用户

WHERE attribute_id = 1 AND value = 'active'

✅ 索引：(attribute_id, value)

场景 3：多属性过滤（EAV 噩梦）

entity_id IN (
  SELECT entity_id FROM eav WHERE attribute_id=1 AND value='active'
)
AND entity_id IN (
  SELECT entity_id FROM eav WHERE attribute_id=2 AND value>'100'
)

✅ 解决方案：

• 临时表
• 物化视图
• 或 反范式宽表

五、高级优化方案（强烈推荐）

✅ 方案 A：EAV + 宽表（最常见）

users (
  id,
  status,
  level,
  created_at
)

EAV 只存“扩展属性”

✅ 方案 B：按属性类型分表

eav_string
eav_int
eav_datetime

索引简单、查询快

✅ 方案 C：JSON 替代 EAV（现代做法）

ALTER TABLE users ADD attrs JSONB;

CREATE INDEX idx_attrs ON users USING gin(attrs);

✅ PostgreSQL 推荐

六、不推荐的索引

❌ 只对 value 建索引
❌ 对 TEXT value 建完整索引
❌ 在 EAV 上做复杂 JOIN + 排序

七、一句话总结

EAV 索引 = (entity_id, attribute_id) 打底 + (attribute_id, value) 补查询 + 类型分表 / JSON 才是正道

如果你愿意，可以告诉我：

• 用的数据库（MySQL / PG / Oracle）
• 查询场景（OLTP / 报表）
• 数据量级

我可以直接帮你画索引方案或写 DDL。