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占位。
