能，MySQL 8.0 的 JSON 类型可直接存问卷答案，但须用 JSON 字段（非 TEXT/VARCHAR），配合 JSON_VALID() 校验、路径查询（如 $.q1）、生成列+索引提升性能，并通过 CHECK 约束保障基础结构。
MySQL 8.0 的 JSON 类型是否真能直接存问卷答案？
能，但必须用 JSON 类型字段，不能用 TEXT 或 VARCHAR 伪装。MySQL 8.0 对 JSON 类型做了完整支持：写入时自动校验格式、提供 JSON_VALID() 函数、支持路径查询（如 $.q1）、可建函数索引。如果只是把 JSON 字符串塞进 TEXT 字段，后续查单个题项、加索引、做约束都无从谈起。
常见错误现象：INSERT INTO survey_answers (data) VALUES ('{"q1":"a","q2":null}'); 在 TEXT 字段能成功，但在 JSON 字段会因 null 值（非字符串 "null"）报错 Invalid JSON text —— MySQL 要求 JSON 中的 null 必须是字面量，不是字符串。
- 建表时明确指定字段类型为
JSON：data JSON NOT NULL - 插入前用
JSON_VALID()预检（尤其对接前端提交的原始字符串）：SELECT JSON_VALID('{"q1":"yes"}'); - 避免在应用层拼接 JSON 字符串；优先用语言原生结构序列化（如 Python 的
json.dumps()），再交给 MySQL 处理
怎么高效查某道题的所有答案，比如“用户对功能 A 的满意度”？
别用 LIKE 模糊匹配 JSON 字符串，性能差且不可靠。应使用 MySQL 内置的路径提取函数，配合生成列 + 索引提升查询速度。
例如问卷中满意度题字段为 q_satisfaction，对应 JSON 内路径 $.satisfaction：
ALTER TABLE survey_answers ADD COLUMN satisfaction_score TINYINT AS (data->>'$.satisfaction') STORED, ADD INDEX idx_satisfaction (satisfaction_score);
之后就能走索引查：SELECT * FROM survey_answers WHERE satisfaction_score > 3;
-
->>是推荐操作符（自动转义并去引号），->返回带引号的 JSON 字符串，容易出错 - 生成列必须声明为
STORED才能建索引；VIRTUAL列不落盘，无法索引 - 路径表达式区分大小写：
$.Satisfaction和$.satisfaction是不同键 - 若答案是多选数组（如
["a","c"]），需用JSON_CONTAINS(data, '"a"', '$.features')查询，不能用=
如何防止脏数据写入 JSON 字段，比如缺题、类型错乱？
MySQL 8.0 不支持 JSON Schema 校验，但可通过生成列 + CHECK 约束组合实现轻量级结构保障。
例如强制要求必答字段 user_id 和 submit_time 存在，且 age 是整数：
ALTER TABLE survey_answers ADD COLUMN _required_fields_ok BOOLEAN AS ( JSON_CONTAINS_PATH(data, 'one', '$.user_id', '$.submit_time') AND JSON_TYPE(data->>'$.age') = 'INTEGER' ) STORED, ADD CONSTRAINT chk_json_structure CHECK (_required_fields_ok);
-
JSON_CONTAINS_PATH(..., 'one', ...)表示至少存在一个路径，'all'才要求全部存在 -
JSON_TYPE()返回字符串（如'STRING'、'INTEGER'），注意大小写 - 约束只在 INSERT/UPDATE 时触发，不影响已有数据；若历史数据不合规，需先清理再加约束
- 复杂校验（如选项值只能是预设枚举）仍需在应用层拦截，数据库层只做基础兜底
用 JSON 存问卷，会不会让 JOIN 和聚合变慢？
会，但可控。JSON 字段本身不能直接参与 JOIN 条件或 GROUP BY，必须先提取成生成列，再基于该列操作。否则每次查询都要解析整个 JSON 文本，CPU 开销大，且无法利用索引。
典型反模式：SELECT COUNT(*) FROM survey_answers WHERE data->>'$.source' = 'mobile'; —— 全表扫描 JSON 字段，无索引可用。
- 高频查询字段（如来源、地区、版本号）务必提前建生成列 + 索引
- 聚合统计尽量避免嵌套 JSON 操作；例如统计各题项选择分布，应先用生成列展开，再
GROUP BY - JSON 字段体积大会显著增加 InnoDB 页面压力；单条记录超过 8KB 容易触发行溢出，影响缓冲池效率
- 备份与主从同步不受影响，但慢查询日志里 JSON 内容会被截断，排查时注意看
data字段实际长度
真正麻烦的不是语法，而是团队对“JSON 字段可随意扩展”的误判——一旦业务要求按某新题项做实时筛选或权限隔离，而该字段没提前建生成列和索引，补救成本远高于初期多写两行 ALTER TABLE。
