MySQL JSON 类型适合什么场景？查询和索引有哪些注意点？

简化版

MySQL JSON 类型适合存储结构不完全固定、扩展属性较多、查询频率不高或只查询少数路径的数据。它比纯文本更能保证 JSON 合法性，也提供 JSON 函数。但 JSON 不是替代关系模型的万能方案，频繁查询、过滤、关联、统计的字段应拆成普通列，或提取成生成列并建立索引。

详细版

JSON 字段常用于用户扩展属性、事件埋点、第三方回调原文、配置快照等。它的优势是灵活，缺点是约束弱、查询复杂、索引不如普通列直观。

如果业务经常按 JSON 中的某个字段筛选，例如 payload.userId，直接在 JSON 表达式上查询可能性能差。常见优化是用生成列提取该路径，再给生成列建索引。重要业务字段不要长期藏在 JSON 里，否则数据质量和性能都会受影响。

面试中要强调“灵活性和可治理性”的取舍。

完整版教学

一、JSON 类型的价值

JSON 能保存半结构化数据。

字段结构可以随业务扩展。

MySQL 会校验写入内容是否为合法 JSON。

数据库提供路径提取、判断、修改等函数。

它比把 JSON 当普通 TEXT 更可控。

二、适合场景

第三方接口回调原文。

埋点事件扩展字段。

低频查询的附加属性。

灰度配置和实验参数快照。

结构变化快但不作为核心查询条件的数据。

三、不适合场景

核心查询条件不适合长期放 JSON。

频繁 JOIN 的字段不适合放 JSON。

需要强约束的数据不适合只靠 JSON。

高频统计指标不适合每次从 JSON 中解析。

这类字段更应该设计成普通列。

四、查询示例

SELECT id
FROM events
WHERE JSON_UNQUOTE(JSON_EXTRACT(payload, '$.type')) = 'click';

不同版本 MySQL 也支持更简洁的 JSON 操作符。

但写法方便不等于性能自动好。

五、索引思路

方案	适用场景	注意点
普通列	核心字段	约束和索引最清晰
生成列 + 索引	查询固定 JSON 路径	要维护表达式和类型
函数索引	支持版本中可用	兼容性要确认
全表扫描解析	低频小数据量	大表风险高

六、生成列优化示例

CREATE TABLE events (
  id BIGINT PRIMARY KEY,
  payload JSON NOT NULL,
  event_type VARCHAR(32) GENERATED ALWAYS AS (
    JSON_UNQUOTE(JSON_EXTRACT(payload, '$.type'))
  ) STORED,
  INDEX idx_event_type (event_type)
);

这样查询 event_type 时可以更容易利用索引。

注意生成列类型要和 JSON 路径值匹配。

JSON 字段可以让模型更灵活，但不能把所有建模责任都推给 JSON。

七、误区和追问

误区：有 JSON 类型就不需要表结构设计。 JSON 只适合部分灵活字段，核心关系仍要建模。
误区：JSON 查询一定能走索引。 直接路径查询通常需要生成列或函数索引支持。
误区：JSON 比 TEXT 总是更快。 JSON 的优势是合法性和函数支持，性能要看查询方式。
追问：为什么不把所有扩展字段拆列？ 字段变化太快、低频使用时，拆列会增加 schema 维护成本。
追问：JSON 中字段类型不一致怎么办？ 要在写入层校验，必要时用生成列类型暴露问题。
追问：JSON 适合存数组吗？ 可以存，但如果要频繁查询数组元素关系，关系表更清晰。

八、面试收束

回答时先说适合半结构化和低频扩展属性。

再提醒核心查询字段应拆列或生成列索引。

最后补充约束、性能和数据治理风险。

简化版

详细版