MySQL三大范式是为减少冗余、避免更新异常提出的结构化约束：1NF要求字段原子化，2NF消除非主属性对部分主键的依赖，3NF消除非主属性间的传递依赖；范式化需结合业务权衡，必要时可适度反范式。
MySQL 数据库设计中的三大范式，本质是为减少数据冗余、避免更新异常而提出的结构化约束原则。它不是强制标准，而是指导思路——用得恰当能提升一致性与可维护性，生搬硬套反而增加复杂度。
第一范式（1NF）：字段原子化
核心要求是表中每个字段都不可再分，即保证“列的原子性”。比如“地址”字段不能存“北京市朝阳区建国路8号”，而应拆成 province、city、district、street 等独立列；又如“标签”不能用逗号拼接（"java,mysql,web"），而应通过关联表实现多对多关系。
- 常见违反场景：JSON 字符串存多值（如用户兴趣 ["阅读","跑步"]）、复合姓名字段（"张三/男/28"）
- 建议：若某字段常需按子项查询或筛选，大概率该拆；JSON 类型仅适用于不参与条件检索、纯存储场景
第二范式（2NF）：消除非主属性对部分主键的依赖
前提是满足 1NF，且表有复合主键（多个字段联合唯一标识一行）。此时，所有非主键字段必须完全依赖整个主键，而不能只依赖其中一部分。
- 典型反例：订单明细表 (order_id, product_id, product_name, quantity)，主键为 (order_id, product_id)。product_name 只依赖 product_id，与 order_id 无关 → 违反 2NF
- 解决方法：将 product_name 移到独立的 products 表中，明细表只保留 product_id 作外键
- 注意：若表只有单字段主键，天然满足 2NF，无需额外检查
第三范式（3NF）：消除传递依赖
在满足 2NF 基础上，要求非主属性之间不能存在依赖关系。即：若 A → B，B → C，且 B 不是候选键，则 A → C 是传递依赖，C 就不该留在当前表。
- 例子：学生表 (student_id, name, dept_name, dept_head)，其中 dept_name → dept_head。dept_head 并不直接依赖 student_id，而是通过 dept_name 间接获得 → 违反 3NF
- 优化方式：拆出院系表 (dept_name, dept_head)，学生表只保留 dept_name 外键
- 关键判断：问自己“这个字段是否描述的是本实体的特征？”——如果不是，就该归到它真正归属的实体表中
范式化不是终点。实际开发中，适度反范式（如冗余字段、宽表）常用于提升查询性能，尤其在读多写少、报表统计等场景。关键是理解每条规则背后的意图，再根据业务权重、数据规模和访问模式做权衡。
