MySQL中多列存储与JSON列存储选型及百亿级数据性能对比

是否应该调整为JSON列？ #

不能直接判定哪种结构更优，核心要看你的业务场景：

• 若新增字段频繁：原生列结构每次加字段都要执行DDL，在10^9条数据的大表上，这类操作可能耗时数小时甚至更久，还可能锁表影响业务连续性。改用JSON列可以完全规避频繁的结构变更，灵活性拉满。
• 若依赖字段做查询/聚合：如果业务中经常需要按C1、C2这类字段过滤、排序、做统计分析，原生列的性能会碾压JSON列——原生列可构建高效的B树/哈希索引，查询时直接定位数据；而JSON字段即便支持索引（比如MySQL的JSON路径索引、PostgreSQL的jsonb索引），索引维护和查询效率也远不如原生列，聚合操作的开销更是大得多。
• 若看重数据一致性：原生列可通过数据库约束（非空、类型校验、唯一约束）保障数据质量；JSON列的字段类型、键名存在性很难用数据库层面的规则管控，容易出现键名拼写错误、类型不统一的脏数据，后期排查成本极高。

亿级数据规模下的读写更新性能差异 #

读性能 #

• 原生列：如果查询用到索引，能快速定位目标数据，且仅读取所需列，IO开销极小；即便全表扫描，行存数据库只会加载必要列，列存数据库的优势更明显，性能稳定高效。
• JSON列：读取JSON内的字段需先解析整个JSON对象，单条数据的解析开销看似不大，但亿级数据叠加后会非常可观；若按JSON字段过滤，无索引时每条数据都要解析后判断，性能比原生列差几个数量级；就算有JSON索引，查询时的索引匹配、回表开销也远高于原生列索引。

写性能 #

• 原生列：插入数据时直接写入对应列，开销稳定；但新增字段的DDL操作是致命问题——亿级表加列可能导致长时间锁表，业务完全停摆。
• JSON列：插入时需序列化JSON对象，有一定额外开销，但胜在无需频繁DDL；不过批量插入场景下，JSON序列化的累计开销会比原生列插入大不少。

更新性能 #

• 原生列：更新单个列时，数据库只需定位到该行对应列的存储块，修改数据即可，IO开销小，并发场景下的行锁粒度更优，冲突概率低。
• JSON列：多数数据库不支持JSON字段的部分更新，需先读取整个JSON、修改后再写回，相当于整行更新，IO开销是原生列更新的数倍；即便部分数据库支持部分更新（比如PostgreSQL的jsonb_set），底层操作的复杂度也远高于原生列更新，高并发下性能下降明显。

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