MySQL范式是规范数据库设计的数学化规则，目标是提升数据清洁性、可靠性与可维护性；1NF要求字段原子性，2NF消除部分依赖，3NF消除传递依赖，实际应用中3NF为推荐起点，高范式需权衡性能与复杂度。
MySQL中的范式，是一套用于规范数据库表结构设计的数学化规则，核心目标是让数据更干净、更可靠、更易维护。它不是强制命令，而是经过长期实践验证的设计指南——用得好，能避开重复存储、改一处漏多处、删数据丢配置等典型坑。
第一范式（1NF）：字段必须“不可再分”
这是关系型数据库的底线要求。每列只能存一个原子值，不能是逗号分隔的列表、JSON对象、地址+电话拼接串等。
- ❌ 反例：用户表里有个contact_info字段，值为“北京市朝阳区|138XXXX1234|张三”
- ✅ 正确做法：拆成province、city、phone、name四个独立字段
- 关键判断标准：该字段能否用SQL的WHERE或ORDER BY直接精准过滤？如果要SUBSTRING_INDEX或JSON_EXTRACT才能取值，大概率已违反1NF
第二范式（2NF）：非主键字段必须“全靠主键”
前提是满足1NF，并且有明确主键（含联合主键）。它解决的是“只靠主键一部分就能确定某字段”的问题，也就是部分依赖。
- ❌ 反例：订单明细表(order_id, product_id, quantity, unit_price, product_name)，主键是(order_id, product_id)，但product_name只和product_id有关，与order_id无关
- ✅ 正确做法：把产品信息单独抽成products表，原表只保留product_id作为外键
- 好处：修改产品名称只需更新一行；新增产品不用绑定订单；避免同一产品在多条订单中反复写入相同名字
第三范式（3NF）：禁止“靠别人间接靠主键”
在2NF基础上，进一步消除传递依赖——即非主键字段A依赖于非主键字段B，而B才依赖于主键。
- ❌ 反例：学生表(student_id, name, dept_name, dept_head)，主键是student_id，dept_head不直接由student_id决定，而是先通过dept_name，再得到负责人
- ✅ 正确做法：拆出departments表（dept_name为主键），学生表只存dept_name外键
- 关键信号：当你发现两个非主键字段总是一起出现、一起修改（比如改学院名就得同步改院长名），基本就是3NF漏洞
范式不是越高越好，得看场景
实际项目中，严格做到BCNF甚至4NF反而可能拖慢查询。比如报表类系统常把维度信息冗余进事实表（如把商品类目名直接存在订单明细里），省去JOIN，提升BI查询速度。这种反范式不是偷懒，而是有意识的权衡。
- 推荐起点：绝大多数业务系统做到3NF就足够稳了
- 谨慎升级：BCNF对唯一性约束更严，但会显著增加表数量和关联复杂度
- 允许妥协：读多写少、实时性要求高的模块，可局部反范式；核心交易链路（如支付、库存）仍建议守住3NF底线
