数据库范式是关系型数据库设计中用于规范数据结构、减少冗余、避免异常的三层递进规则：1NF要求字段原子性，2NF消除部分依赖，3NF消除传递依赖；实际应用需在规范化与性能间权衡。
数据库范式是关系型数据库设计中用于规范数据结构、减少冗余、避免异常的一套规则。MySQL本身不强制执行范式，但遵循范式能显著提升数据一致性、可维护性和查询效率。三大范式层层递进，每满足更高一级，都以前一级为基础。
第一范式（1NF）：保证字段原子性
核心是“列不可再分”。表中每一列必须是单一、不可拆分的值，不能出现逗号分隔的多个值，也不能把地址、联系方式等复合信息塞进一个字段里。
- 反例：
contact_info字段存 “张三,13800138000,北京朝阳区xx路” —— 这违反1NF，因为一个字段混了姓名、电话、地址三种信息 - 正确做法：拆成
name、phone、city、address等独立列；如果地址需进一步筛选（如按省/市），还可继续垂直拆分 - 注意：MySQL默认存储行为不自动阻止非原子值，是否满足1NF完全取决于建表时的设计意识
第二范式（2NF）：消除对主键的部分依赖
前提：已满足1NF，且表有明确主键（推荐用自增ID或业务无关的唯一标识）。要求所有非主键字段必须完整依赖于整个主键，不能只依赖联合主键中的一部分。
- 典型问题场景：联合主键（学号, 课程号）→ 成绩、姓名、教师。这里“姓名”只依赖“学号”，与“课程号”无关，属于部分依赖，违反2NF
- 解决方式：把“姓名”及相关学生信息（如院系、入学年份）单独抽成
students表，原表只保留学号、课程号、成绩，并用外键关联 - 效果：新增未选课的学生也能插入，删除某门课不会误删学生信息，避免更新异常
第三范式（3NF）：消除对主键的传递依赖
前提：已满足2NF。要求非主键字段之间不能存在依赖关系——即不能出现“A决定B，B决定C，而A不直接决定C”的链式依赖。
- 常见例子：员工表含
emp_id（主键）、name、dept_name、dept_head。其中dept_name → dept_head，而emp_id → dept_name，导致dept_head间接依赖于emp_id，违反3NF - 解决办法：将部门信息独立为
departments表（dept_name主键，dept_head字段），员工表只保留emp_id、name、dept_name，通过外键引用 - 好处：部门负责人变更只需改一次，不会因多条员工记录重复存储而漏改；也避免插入时因部门不存在而无法录入员工
范式不是越高越好。实际项目中常在3NF基础上适度反范式（如冗余少量计算字段、合并高频关联表），以换取查询性能。关键是在理解原理的前提下做权衡，而不是机械套用。
