数据库范式是关系型数据库设计中用于规范数据结构、减少冗余、避免异常的一套规则。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基础上适度反范式（如冗余少量计算字段、合并高频关联表），以换取查询性能。关键是在理解原理的前提下做权衡，而不是机械套用。
