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 字段通常无法走索引，必须配合特定手段：
-
red">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），避免读出-修改-写回，减少并发冲突
