SQL范式是减少冗余、避免异常、保障一致性的关系型数据库设计规则体系，含1NF（字段原子性）、2NF（消除部分依赖）、3NF（消除传递依赖），但需依场景权衡，避免过度规范化影响性能。
SQL范式是一套用于指导关系型数据库表结构设计的规则体系，核心目标是减少数据冗余、避免更新异常、保障数据一致性。它不是硬性编码规范，而是逻辑组织数据的方法论，从低到高逐级增强约束力。
第一范式（1NF）：确保字段原子性
每列值必须是不可再分的最小数据单元。比如“地址”字段不能存成“北京市朝阳区建国路8号”，而应拆为 province、city、district、street 等独立列；但实际中需权衡——若业务从不按区域统计，“地址”单字段反而更实用。现代DBMS默认阻止非原子存储，所以1NF通常是自然满足的底线。
第二范式（2NF）：消除部分依赖
在满足1NF前提下，要求所有非主键字段必须完全依赖整个主键，不能只依赖联合主键的一部分。例如订单明细表若以 (order_id, product_id) 作联合主键，而 discount_rate 只随 order_id 变化，就违反2NF。解决方式是把 discount_rate 移到订单主表，明细表只保留与两者都相关的字段（如 quantity、unit_price）。
第三范式（3NF）：消除传递依赖
在满足2NF基础上，非主键字段之间不能有依赖关系。典型反例：用户表含 user_id、name、dept_id、dept_name —— dept_name 不直接依赖 user_id，而是通过 dept_id 间接获得，属于传递依赖。应拆分为 users 表（user_id, name, dept_id）和 depts 表（dept_id, dept_name），用外键关联。
范式不是越高越好，要结合场景取舍
过度规范化会增加 JOIN 次数，拖慢高频查询。常见折中做法包括：
- 在订单表里冗余 user_name，省去每次查用户表
- 商品快照中保存当时的 price 和 category_name，锁定历史状态
- 日志类宽表允许适度重复，优先保障写入吞吐和查询简单性
判断是否该反规范化，关键看读写比例、数据变更频率、一致性容忍度——金融账务必须强一致，推荐3NF；电商商品页展示则常以空间换时间。
