SQL 中避免大量 NULL 字段的核心是将稀疏属性从宽表剥离，采用 EAV 模型、JSON 字段、垂直拆分主子表、枚举关联表等灵活建模方式，适配业务稀疏性而非强行填满字段。
SQL 中避免大量 NULL 字段，核心是把稀疏属性从宽表结构中剥离，改用更灵活的建模方式——不是靠“填满字段”来设计表，而是让数据结构适配业务的稀疏性。
用 EAV 模型处理高度动态的稀疏属性
EAV（Entity-Attribute-Value）是一种经典解法：把原本分散在几十个 NULL 列里的可选属性，拆成三张小表——实体表（如products）、属性定义表（如attributes）、值存储表（如product_attributes）。每个属性只存它真正存在的那几条记录，彻底消除 NULL。
- 适合场景：商品规格（手机有“屏幕尺寸”，衣服有“尺码”，但两者属性完全不同）
- 注意点：查询需 JOIN，不适合高频聚合；加索引时优先考虑
(entity_id, attribute_id) - 小优化：对常用属性可冗余一两个字段（如
main_color）兼顾性能和灵活性
用 JSON 字段承载非结构化、低查询频率的稀疏数据
PostgreSQL、MySQL 5.7+、SQL Server 2016+ 都支持原生 JSON 类型。把变化多、不参与 WHERE 或 JOIN 的字段（如“用户自定义表单数据”“设备上报的传感器扩展字段”）塞进一个 metadata JSON 字段里，主表保持紧凑。
- 优势：写入自由，不用改表结构；查询时可用
->或JSON_EXTRACT按需取值 - 限制：无法直接建普通 B -tree 索引；高频检索某个 JSON 内字段时，可用生成列 + 索引（如 MySQL 的
ALTER TABLE ADD COLUMN brand VARCHAR(50) AS (data->>"$.brand") STORED）
按业务域垂直拆分，用主子表替代宽表
把逻辑上属于不同主题的稀疏字段，拆成独立子表。例如用户表不堆“微信 openid、 支付宝 user_id、 抖音 union_id、 邮箱 验证码、短信验证码……”，而是建 user_social_links、user_contacts、user_verifications 等子表，每条记录只对应一个真实值。
- 好处：主表轻量，关联清晰；新增渠道无需改主表；历史数据自然归档
- 关键：外键约束 + 合理的 ON DELETE 策略（比如 CASCADE 或 SET NULL）要提前想清楚
用枚举 + 关联表替代“开关型”稀疏字段
别建 20 个 is_xxx_enabled TINYINT 字段。把这类状态抽象为“功能开关”实体，用一张 user_features 表管理：user_id、feature_code、enabled、updated_at。新增功能只需 INSERT 一行，而不是 ALTER TABLE 加列。
- 典型适用：SaaS 产品的模块权限、灰度开关、个性化配置项
- 查询提速：给
(user_id, feature_code)建唯一联合索引
基本上就这些。稀疏不是缺陷，是业务真实的表达方式——建模的关键，是让结构跟着数据的“存在性”走，而不是强行用 NULL 占位。
