拆表更适合高频查询和强一致性场景，如用户标签需频繁JOIN、筛选、事务操作；JSON适合低频读写、结构松散、不参与条件查询的配置类数据；混合方案最实用，核心字段拆表、扩展字段存JSON。
拆成关联表更适合高频查询和强一致性场景
如果集合数据需要频繁被筛选、排序、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。
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 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 更灵活，但也让约束更隐形；拆表看着笨重，却把校验逻辑交给了数据库引擎
