JSON字段适合存储灵活、非核心的半结构化数据，如用户配置、日志扩展、临时字段及小规模从属数据；关键业务属性须独立建列，避免高频检索场景；优先选用PostgreSQL jsonb或MySQL生成列索引优化查询。

JSON字段在SQL数据库中适合存储结构灵活、变动频繁或非核心的半结构化数据，但不能替代规范化的表设计。用得好能提升开发效率，用得不当会拖慢查询、增加维护成本。

什么时候该用JSON字段

适合以下场景：

• 用户自定义配置（如仪表盘布局、通知偏好）
• 日志类扩展信息（如API调用的原始请求头、错误上下文）
• 临时性或实验性字段（尚未确定是否长期保留）
• 一对多关系中从属数据量小、不参与关联统计（如商品的多个规格描述，但不按规格筛选）

避免用于需要高频检索、排序、聚合或外键约束的字段——比如“订单状态”“用户等级”“创建时间”这类关键业务属性，应始终放在独立列中。

不同数据库对JSON的支持差异

MySQL 5.7+ 提供 JSON 类型和 JSON_EXTRACT() 函数，支持部分索引（通过生成列）；PostgreSQL 的 jsonb 类型性能更优，支持 GIN 索引和丰富操作符（如 @>、?）；SQL Server 2016+ 支持 NVARCHAR(MAX) 存储 + OPENJSON 解析，但原生 JSON 功能较弱。

建议：优先选 jsonb（PostgreSQL）或带生成列索引的 JSON（MySQL），避免仅用字符串存 JSON 后手动解析。

查询优化的关键做法

直接用函数查 JSON 字段通常无法走索引，必须配合特定手段：

• MySQL：为常用路径建虚拟生成列 + 普通索引，例如：
  ALTER TABLE orders ADD status VARCHAR(20) AS (JSON_UNQUOTE(JSON_EXTRACT(metadata, '$.status'))) STORED;
  再对 status 列加索引
• PostgreSQL：对 jsonb 字段建 GIN 索引，支持键存在、键值匹配等查询：
  CREATE INDEX idx_orders_meta ON orders USING GIN (metadata);
  查询时用 WHERE metadata @> '{"status":"shipped"}'
• 避免全表扫描：不在 WHERE 中直接写 JSON_CONTAINS(metadata, '"shipped"', '$.status') 这类无索引支撑的表达式

写入与维护注意事项

JSON 字段不是“万能收纳盒”：

• 写入前校验格式，防止非法 JSON 导致后续查询失败（应用层或触发器校验）
• 定期清理过期或冗余字段，JSON 容易越积越大，影响备份和主从同步
• 不要在 JSON 中存敏感信息（如密码、身份证号），难以加密和审计
• 更新单个字段时，尽量用数据库原生函数（如 JSON_SET、jsonb_set），避免读出-修改-写回，减少并发冲突