SQL数据库范式是为解决数据冗余、更新/插入/删除异常而设计的规范化原则，包含1NF（字段原子性）、2NF（消除部分依赖）、3NF（消除传递依赖），实际应用中需权衡规范与性能。
SQL数据库范式，本质是为了解决数据冗余、更新异常、插入异常和删除异常而设计的一套规范化规则。它不是硬性标准，而是指导我们如何合理组织表结构的实用原则。真正用好范式，关键不在死记条文，而在理解每一条背后要解决什么问题。
第一范式（1NF）：字段不可再分
核心是“原子性”——表中每个字段的值都必须是不可分割的最小单元。
- 错误示例：用户表里有个“地址”字段，存的是“北京市朝阳区建国路8号万达广场A座1201”，这违反1NF，因为地址包含省、市、区、街道、楼号等多个逻辑部分；
- 正确做法：拆成province、city、district、street、building等独立字段；
- 注意：JSON字符串或逗号分隔的标签列表（如“Java,Python,SQL”）也属于非原子值，应通过关联表实现多对多关系。
第二范式（2NF）：消除非主属性对部分主键的依赖
前提是满足1NF，且只在存在复合主键（多个字段联合做主键）时才有意义。
- 典型问题：订单明细表用（order_id, product_id）作联合主键，但product_name只依赖product_id，不依赖order_id，这就叫“部分依赖”；
- 解决方法：把product_name等产品信息移到单独的products表中，明细表只保留order_id、product_id、quantity等真正与订单+商品组合相关的字段；
- 如果表只有单字段主键，那只要满足1NF，就自动满足2NF。
第三范式（3NF）：消除传递依赖
在满足2NF基础上，要求所有非主属性都直接依赖于主键，不能通过其他非主属性间接依赖。
- 反面例子：员工表含emp_id（主键）、dept_id、dept_name。这里dept_name不直接依赖emp_id，而是通过dept_id间接得到——即emp_id → dept_id → dept_name，这就是传递依赖；
- 修复方式：把部门信息抽成departments表，员工表只保留dept_id作为外键；
- 判断口诀：如果某个非主字段的值，能靠另一个非主字段“查出来”，那就很可能违反3NF。
基本上就这些。范式不是越高越好，实际开发中常在3NF基础上适度反规范化（比如冗余少量字段提升查询性能），但前提是你清楚自己在打破哪条规则、为什么值得打破。理解范式，是为了让数据更可靠、逻辑更清晰，而不是为了贴标签。
