首先得说，你的思路其实抓住了JSON类型在存储空间利用上的一个核心优势——只存储实际用到的字段，这确实能在两类用户非共享字段较多、且单条记录里空字段占比高的场景下节省空间。但为什么大家普遍更推荐范式化分表方案？主要是JSON方案存在几个容易被忽略的隐性问题，咱们一个个拆解：

1. 数据一致性难以保障 #

普通字段可以通过NOT NULL、ENUM、CHECK等约束强制数据的合法性，但JSON内部的字段MySQL无法直接施加这类约束。比如A类用户必须填写的某个独有字段，用JSON存储时很容易出现漏存、格式错误（比如本该是数字却存了字符串）的情况，后期排查数据脏问题会非常耗时。而分表方案中，每个用户类型的表可以严格定义字段约束，从底层就保障了数据一致性。

2. 复杂查询的性能与灵活性受限 #

虽然你通过虚拟列+索引解决了单个字段的查询性能问题，但如果涉及多字段组合查询、聚合分析等场景，JSON的劣势就会凸显：

• 组合查询时，即使给多个JSON字段都创建了虚拟列，SQL写法会比普通字段复杂得多，MySQL优化器对JSON相关查询的执行计划优化也不如普通字段成熟，容易出现低效的扫描。
• 聚合操作（比如统计某个JSON字段的平均值、分组统计）需要先解析JSON，额外的解析开销会拖慢查询速度，远不如直接对普通字段操作高效。

3. 长期维护成本更高 #

JSON的字段结构是“隐含”的——它没有在表结构中明确定义，而是依赖业务代码来维护结构一致性。这会带来几个问题：

• 团队新人接手时，很难快速了解所有字段的含义和约束，容易出现误用。
• 当需要新增/修改非共享字段时，无法通过ALTER TABLE统一更新结构，只能靠代码逻辑控制，很容易出现新旧数据结构不一致的情况。
• 排查问题时，无法直接通过DESCRIBE查看字段信息，必须查询JSON字段的实际内容，效率极低。

4. 隐性的性能损耗 #

MySQL的JSON是二进制存储，但单条记录如果包含大量JSON数据，会导致单条记录过大，进而引发InnoDB的页分裂问题，间接影响读写性能。另外，备份恢复时，JSON字段的解析开销也会比普通字段大，增加数据迁移的成本。

什么时候你的方案是可行的？ #

如果你的场景满足以下几个条件，JSON方案其实是可以考虑的：

• 两类用户的非共享字段极少（比如2-3个）；
• 只需要对极少数JSON字段做查询，且已经通过虚拟列建立了索引；
• 对数据一致性的要求较低，或者业务代码能严格保障JSON结构的合法性；
• 团队有成熟的JSON字段维护规范（比如用JSON Schema做校验）。

但从长期的可扩展性、维护性和性能上限来看，范式化分表依然是更稳妥的选择。

内容的提问来源于stack exchange，提问作者Joseph