拆成关联表更适合高频查询和强一致性场景
如果集合数据需要频繁被筛选、排序、JOIN 或参与事务，必须拆成独立表。比如用户标签
user_tags表（
user_id,
tag_id），配合索引后
SELECT * FROM users JOIN user_tags USING (user_id) WHERE tag_id = 123能走索引，毫秒级响应。用 JSON 存的话，MySQL 5.7+ 虽支持
JSON_CONTAINS()，但无法使用普通索引，只能建函数索引（如
CREATE INDEX idx_tags ON users ((CAST(JSON_EXTRACT(tags, '$[*]') AS UNSIGNED)))），维护成本高且效果有限。 拆表后可对
tag_id单独建索引，查询效率稳定 外键约束能保证
user_id和
tag_id的存在性，避免脏数据 分页、去重、统计（如「有多少用户打了 3 个以上标签」）直接用 SQL 表达，无需应用层解析 但写入变重：一次打 5 个标签，要执行 5 条
INSERT或 1 条批量
INSERT ... VALUES (),(),()
JSON 字段适合低频读写、结构松散、不参与条件查询的场景
比如用户个人配置项：
{"theme": "dark", "notify_email": true, "recent_searches": ["mysql", "json"]}。这类数据极少用于 WHERE过滤，也不需要按某个字段排序，只是整块读出/覆盖写入。此时用
JSON类型比拆成
user_settings表更轻量——少建表、少 JOIN、迁移时字段增减不改 schema。 MySQL 8.0+ 对
JSON字段有原生优化，
JSON_EXTRACT()性能尚可，但别在
WHERE里大量用
JSON_CONTAINS(col, '"abc"')不能加传统索引，想加速某字段需建生成列 + 索引，例如：
ALTER TABLE users ADD COLUMN theme VARCHAR(20) AS (JSON_UNQUOTE(JSON_EXTRACT(settings, '$.theme'))) STORED;<br>CREATE INDEX idx_theme ON users (theme);应用层序列化/反序列化负担转移给了数据库，注意
JSON_VALID()校验，避免插入非法 JSON 导致后续查询失败
混合方案常被低估但实际最实用
把「稳定核心字段」拆表，「动态扩展字段」放 JSON。例如电商订单：订单主表
orders存
order_id,
user_id,
status；订单项必须拆成
order_items表（涉及库存扣减、发票明细等强事务逻辑）；而「买家留言」「物流备注」「营销活动快照」这些非关键、只读多、结构不定的数据，存在
orders.ext_info的
JSON字段里更合适。 避免为 20% 的边缘字段拖累 80% 的主流程性能 历史数据兼容性好：新活动加字段，老订单
ext_info缺失该 key 不影响解析 警惕 JSON 嵌套过深（>3 层）或单条超 1MB，MySQL 的 JSON 函数处理大文本会明显变慢
别忽略应用层和运维的真实成本
技术选型最终卡在团队熟悉度和监控能力上。如果 DBA 对
JSON函数排查慢查不熟，或者监控系统压根不采集
JSON_EXTRACT的执行耗时，那再“合理”的 JSON 设计也会在线上变成黑盒瓶颈。同理，过度拆表导致
JOIN达到 7 张以上，ORM 自动生成的 SQL 可读性崩坏，开发 debug 成本陡增。 上线前用真实数据量压测：100 万用户，每人平均 8 个标签，拆表 vs JSON 的查询 P99 延迟差多少？ 检查备份恢复时间——含大 JSON 字段的表，
mysqldump可能比纯数字表慢 3 倍，因为要 escape 和格式化字符串 JSON 不是银弹，它让 schema 更灵活，但也让约束更隐形；拆表看着笨重，却把校验逻辑交给了数据库引擎
