JSON字段替代可空字段：查询性能损耗与潜在风险咨询

性能损耗对比 #

• 原生可空字段的查询性能是天花板级别的——数据库能直接利用索引快速定位，不管是等值匹配、范围筛选还是排序，效率拉满。
• JSON字段的性能分两种情况：
  • 只是提取JSON里的内容做展示？那性能差异几乎可以忽略。但要是基于JSON内的字段做过滤、排序，没建索引的话就是灾难——数据库得全表扫描每一行，再解析JSON内容，数据量过万后卡顿会非常明显。
  • 部分数据库（MySQL 5.7+、PostgreSQL）支持给JSON字段建索引：比如MySQL可以给json_col->>'$.target_key'创建普通索引，PostgreSQL用jsonb类型加GIN索引，能把查询性能拉到接近原生字段的水平，但代价是写入数据时要额外维护索引，会增加一点写入延迟。

你需要警惕的其他隐患 #

• 数据乱套风险：JSON是无结构的，数据库没法约束里面的字段类型、必填性。比如你想存整数age，结果不小心存了字符串"25"，后续做计算或筛选直接报错；而原生字段可以通过类型约束、NOT NULL规则把这类问题掐死在写入阶段。
• SQL写起来闹心：查询JSON字段的语法繁琐，比如MySQL里要写json_extract(user_info, '$.address.city')或者user_info->>'$.address.city'，嵌套个几层的话，SQL会变得像乱码，可读性极差，还容易写错。
• 统计分析麻烦死：做报表、聚合查询的时候，原生字段直接用COUNT、SUM就行，JSON字段得先提取再处理，不仅代码啰嗦，性能也差一大截；而且很多BI工具对JSON字段的支持很拉胯，分析数据时额外增加很多工作量。
• 后期迁移成本高：如果哪天想把JSON里的某个字段改成原生字段，得全表遍历解析JSON，数据量大的话这个操作能跑几个小时，期间还可能锁表；而原生可空字段的调整（比如加约束、改类型）就可控多了。

该选哪种？看场景 #

• 选原生可空字段的情况：
  • 这些“部分行才有”的字段是业务核心，经常要查、要筛、要排序或聚合。
  • 字段结构稳定，不会动不动加新字段、改字段类型。
  • 对数据准确性要求高，需要数据库层面的约束兜底。
• 选JSON字段的情况：
  • 字段是边缘属性，很少被查询，只是用来存一些额外的、可有可无的信息。
  • 字段结构不稳定，经常要加新字段，不想频繁改表结构折腾。
  • 存储的是嵌套深、结构不规则的数据，用原生字段会导致表列数爆炸。

最后说句实在的：如果这些字段是业务中常用的，哪怕只有少数行有值，也优先用原生可空字段——多几个可空列而已，换回来的是性能、数据一致性和可维护性的全面提升。如果只是存些偶尔看一眼的扩展信息，JSON字段是更灵活的选择，但要是需要查询，记得给对应的JSON路径建索引，同时在应用层做好数据校验。

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