自定义字段存储数据为什么要选择非关系型数据库

huangguohai

395人浏览 · 2026-04-13 19:03:43

huangguohai · 2026-04-13 19:03:43 发布

需求

如果有这样的需求：针对各种不同的对象模型，由用户自定义属性（可创建、修改、删除属性），然后进行具体数据值的存储。优先使用mongodb这样的非关系型数据库，还是mysql这样的关系型数据库呢

这是一个非常经典的 EAV（Entity-Attribute-Value，实体-属性-值）问题 或 "自定义字段"需求。

结论：强烈建议优先选择 MongoDB，而不是 MySQL。

为什么 MySQL 不擅长这个需求？

方案1：用 EAV 模式（实体-属性-值）

这是 MySQL 解决动态属性的常见但非常糟糕的设计：

-- 元数据表：定义哪些属性
CREATE TABLE attributes (
    id INT PRIMARY KEY,
    attr_name VARCHAR(50),  -- 'color', 'weight', 'material'
    attr_type VARCHAR(20)   -- 'string', 'int', 'date'
);

-- 数据表：每个属性值一行
CREATE TABLE entity_values (
    entity_id INT,           -- 属于哪个实体
    attr_id INT,             -- 哪个属性
    value_string VARCHAR(500),
    value_int INT,
    value_date DATE
);

这个方案的致命问题：

问题	说明
查询极其复杂	查询"颜色=红色且重量>10"需要多次自连接或聚合，SQL 非常难写
性能灾难	每个属性都是一行，100万实体 × 10属性 = 1000万行，查询慢
数据类型混乱	所有值存为字符串，无法利用数据库的类型检查、索引优化
无法强制约束	不能要求"必须有颜色属性"，不能保证颜色值是有效的
维护成本高	动态属性变更需要修改元数据表，影响所有现有数据

方案2：预置大量备用列（如 `custom_field_1`, `custom_field_2` ...）

CREATE TABLE entities (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    custom_field_1 VARCHAR(255),
    custom_field_2 VARCHAR(255),
    ...
    custom_field_50 VARCHAR(255)
);

问题：浪费空间、列数有限、无法处理不同数据类型、字段名无意义、查询需要知道"颜色"对应哪个 custom_field_x。
方案3：用 JSON 列（MySQL 5.7+ 支持）

CREATE TABLE entities (
    id INT PRIMARY KEY,
    dynamic_attrs JSON  -- 存 {"color":"red", "weight":15}
);

这是 MySQL 里相对最好的方案，但仍然不如 MongoDB（见后面对比）。

为什么 MongoDB 天生适合这个需求？

MongoDB 的文档模型就是为这种"动态 Schema"场景设计的。

直接存储方式

// 集合 products
{
  "_id": 1,
  "name": "T恤",
  "color": "红色",      // 用户自定义属性
  "size": "L",
  "material": "棉"
}

{
  "_id": 2,
  "name": "笔记本电脑",
  "cpu": "i7",          // 完全不同的属性集
  "ram": 16,
  "storage": "512GB",
  "color": "银色"       // 也可以有相同的属性名
}

MongoDB 的优势

需求	MongoDB 实现方式
动态添加属性	直接插入新字段，无需修改 Schema
删除属性	`$unset` 操作
修改属性名/类型	直接更新，或迁移脚本简单
查询任意属性	`db.products.find({"color":"红色"})`
查询嵌套属性	`db.products.find({"specs.weight": {"$gt":10}})`
对动态属性建索引	`db.products.createIndex({"color":1})`
混合数据类型	原生支持，同一个属性在不同文档可以是不同类型
属性值校验	可用 JSON Schema 验证器（可选）

性能表现

每个文档独立，没有"空列"浪费空间
查询只涉及需要的文档，不需要 JOIN
索引直接建在动态字段上，效率高
详细对比表：MySQL (JSON列) vs MongoDB

如果你必须在 MySQL 中使用 JSON 列，对比结果如下:

MySQL JSON 示例（对比 MongoDB 的简洁性）

需求：查询 color="红色" 且 weight > 10 的记录

MySQL：

维度	MySQL (JSON列)	MongoDB
动态 Schema	支持，但需要生成虚拟列才能高效查询	原生支持，更自然
查询动态字段	需要 `JSON_EXTRACT()` 函数，语法繁琐	点号语法，简洁
索引动态字段	需要创建"生成列" (Generated Column)，再在生成列上建索引	直接创建普通索引
更新部分属性	`JSON_SET()` 函数	`$set` 操作符，同样原子
深层嵌套操作	支持，但函数嵌套复杂	原生点号语法
数据大小	JSON 存储为文本或二进制（8.0+），有压缩	BSON 二进制，更紧凑
事务支持	✅ 完整的 ACID	✅ 4.0+ 支持多文档事务
聚合查询	JSON 函数有限，复杂聚合困难	强大的聚合管道 (Aggregation Pipeline)
学习曲线	SQL + JSON 函数两套语法	统一的文档操作语法

MySQL JSON 示例（对比 MongoDB 的简洁性）

需求：查询 color="红色" 且 weight > 10 的记录

MySQL：

SELECT * FROM products 
WHERE JSON_EXTRACT(dynamic_attrs, '$.color') = '红色'
  AND JSON_EXTRACT(dynamic_attrs, '$.weight') > 10;

MongoDB：

db.products.find({
  "color": "红色",
  "weight": { "$gt": 10 }
})

需求：对 price 字段建索引

MySQL：

-- 1. 先添加生成列
ALTER TABLE products 
ADD COLUMN price_generated DECIMAL(10,2) 
GENERATED ALWAYS AS (JSON_EXTRACT(dynamic_attrs, '$.price')) STORED;

-- 2. 再建索引
CREATE INDEX idx_price ON products(price_generated);

MongoDB：

// 一步完成
db.products.createIndex({"price": 1})

特殊考虑：如果必须用 MySQL（比如公司强制）

如果被迫使用关系型数据库，推荐以下方案（按优劣排序）：

首选：MySQL JSON 列（上面已对比）
次选：EAV 模式（仅在需要跨属性复杂关系约束时考虑，比如某些属性必须关联另一个表）
最差：备用列方案（几乎不推荐）

但即使是 MySQL JSON 列，也有明显短板：

无法对 JSON 内部字段设置 NOT NULL 或外键约束
复杂聚合查询（如报表）性能差
缺乏 MongoDB 聚合管道的灵活性

最终建议

场景	推荐数据库
用户完全自由定义属性（如 CRM、低代码平台、表单生成器）	MongoDB ✅
属性数量很大（每个实体几十上百个属性）	MongoDB ✅
需要频繁查询/排序/聚合这些动态属性	MongoDB ✅
动态属性和强类型的关系数据混合	混合：MySQL 存固定字段 + MongoDB 存动态属性
公司强制只用 MySQL，且动态属性很少（<5个）	MySQL JSON 列
需要跨属性的复杂事务 + 动态属性很少	MySQL JSON 列（权衡）