mysql中多选数据应使用关联表而非json或text字段，即建users、options、user_option_selections三表，通过联合唯一索引和事务批量操作确保数据一致性与查询效率。
MySQL 不该直接存数组，得拆成关联表
多选框提交的数据本质是多个值的集合，比如用户勾选了 ["java", "python", "go"]。MySQL 的列不支持原生数组类型（JSON 是例外，但不推荐用于查询场景），硬塞进 TEXT 或 JSON 字段会导致无法高效检索、无法建立索引、JOIN 困难、统计逻辑脆弱。真正可维护的做法是用第三张关联表（junction table）。
- 建表时不要用
user_answers表加一个skillsJSON 字段 - 应该有三张表：
users、options（预定义所有可选项，如 id=1 name='java'）、user_option_selections（字段：user_id, option_id, created_at） - 这个关联表必须有联合唯一索引：
UNIQUE KEY `user_option` (`user_id`,`option_id`)，防止重复提交同一选项 - 查询某用户选了哪些技能？
SELECT o.name FROM user_option_selections uos JOIN options o ON uos.option_id = o.id WHERE uos.user_id = 123
插入多选数据时别用循环执行 N 条 INSERT
前端传过来的 skill_ids = [2, 5, 7]，后端如果对每个 ID 都调一次 INSERT INTO user_option_selections...，在高并发下容易因网络延迟或事务未提交导致部分写入失败，还拖慢响应。应该用单条批量 INSERT。
- PHP 示例：
$sql = "INSERT INTO user_option_selections (user_id, option_id) VALUES (?, ?), (?, ?), (?, ?)";，然后绑定参数[123,2,123,5,123,7] - Python（PyMySQL）可用
executemany()，但注意它底层仍是多语句模拟，生产环境更推荐拼成一条VALUES (...),(...),(...) - 务必在事务中执行：先
DELETE FROM user_option_selections WHERE user_id = ?（清旧），再批量INSERT（写新），避免残留脏数据
用 JSON 列不是不行，但只适合只读或低频搜索场景
MySQL 5.7+ 支持 JSON 类型和 JSON_CONTAINS() 函数，看起来能“优雅”存数组。但它在真实问卷系统里很快会暴露短板：
-
JSON_CONTAINS(skills_json, '"python"')无法走索引，全表扫描 —— 10 万份问卷就明显卡顿 - 无法高效统计“选了 Python 又选了 SQL 的人数”，得嵌套
JSON_CONTAINS+ 多次 JOIN，SQL 复杂且慢 - 修改某个选项名称（如把 "javascript" 改成 "JavaScript"）要全表
UPDATE ... SET skills_json = JSON_REPLACE(...)，风险高、锁表久 - 如果只是导出报表用、不查、不统计，那
JSON存一下也无妨；但只要涉及后台筛选、运营分析，立刻切回关联表
前端传参格式和后端校验必须对齐
常见翻车点不是数据库设计，而是前后端约定错位。比如前端把多选框命名为 skills[]，但后端框架（如 Laravel）没开数组解析，结果只收到最后一个值；或者传了字符串 "1,2,3" 而不是数组，后端直接入库，变成脏数据。
- 确认 HTTP 请求体是
application/x-www-form-urlencoded且多选字段确实以数组形式到达（如skills[]=1&skills[]=2） - 后端第一行就要做类型断言：
if (!is_array($skills) || empty($skills)) { throw new InvalidArgumentException('skills must be non-empty array'); } - 过滤非法 ID：
$validIds = array_filter($skills, fn($id) => is_numeric($id) && (int)$id > 0);，再查一遍options表确认这些 ID 全部存在 - 别信前端传来的任何 ID —— 即使加了 disabled 或 hidden，也能被改
