关于 MySQL 的三范式，它们其实是数据库设计的基本原则，主要用于指导我们进行合理的数据库设计，能够有效地减少数据冗余和异常：
第一范式（1NF）：表中的每列的属性不可再分
比如：
| 学号（主键） | 姓名 | 性别 | 就读信息 |
|---|---|---|---|
| 20200101 | 张三 | 男 | 大一，土木工程 |
上表中可以看到，（就读信息）这一列，其实还可以分解成（年级）和（专业），因此（就读信息）这一属性还可以再分，故不满足第一范式
修改成：
| 学号（主键） | 姓名 | 性别 | 年级 | 专业 |
|---|---|---|---|---|
| 20200101 | 张三 | 男 | 大一 | 土木工程 |
第二范式（2NF）：在第一范式的基础上，表里的非主键属性必须都依赖于主键（联合主键）
比如：
| 学号（主键） | 课程（主键） | 教师姓名 | 成绩 | 学生姓名 | 专业 |
|---|---|---|---|---|---|
| 20200101 | C语言程序设计 | 老张 | 80 | 张三 | 计算机科学与技术 |
| 20200102 | JAVA程序设计 | 老李 | 87 | 李四 | 网络工程 |
| 20200103 | 数据结构 | 老王 | 90 | 王五 | 软件工程 |
上表中可以看到，（教师姓名、成绩）两个属性都依赖于（学号）和（课程），但是（学生姓名、专业）这两个属性却只依赖于（学号），不依赖于（课程），即 只需要知道（学号）便可以知道（学生姓名和专业两个属性），所以，导致非主键属性（学生姓名、专业）不完全依赖于主键（学号、课程），故不符合第二范式
修改成：
| 学号（主键） | 课程（主键） | 教师姓名 | 成绩 |
|---|---|---|---|
| 20200101 | C语言程序设计 | 老张 | 80 |
| 20200102 | JAVA程序设计 | 老李 | 87 |
| 20200103 | 数据结构 | 老王 | 90 |
| 学号（主键） | 学生姓名 | 专业 |
|---|---|---|
| 20200101 | 张三 | 计算机科学与技术 |
| 20200102 | 李四 | 网络工程 |
| 20200103 | 王五 | 软件工程 |
第三范式（3NF）：在第二范式的基础上，表中的非主属性不可以存在依赖关系
| 学号（主键） | 姓名 | 性别 | 年级 | 专业 | 班主任姓名 | 班主任性别 | 班主任年龄 |
|---|---|---|---|---|---|---|---|
| 20200101 | 张三 | 男 | 大一 | 计算机科学与技术 | 老张 | 男 | 33 |
| 20200102 | 李四 | 男 | 大二 | 网络工程 | 老李 | 男 | 34 |
| 20200103 | 王五 | 女 | 大三 | 软件工程 | 老王 | 男 | 35 |
上表中可以看到，非主键属性都依赖于（学号），满足了第二范式。但是（班主任性别、班主任年龄）这两个属性都是直接依赖于（班主任姓名）这一属性的，与（学号）属于间接依赖，这就导致了表中的非主键属性存在着依赖关系，不符合第三范式
| 学号（主键） | 姓名 | 性别 | 年级 | 专业 |
|---|---|---|---|---|
| 20200101 | 张三 | 男 | 大一 | 计算机科学与技术 |
| 20200102 | 李四 | 男 | 大二 | 网络工程 |
| 20200103 | 王五 | 女 | 大三 | 软件工程 |
| 班主任姓名（主键） | 班主任性别 | 班主任年龄 |
|---|---|---|
| 老张 | 男 | 33 |
| 老李 | 男 | 34 |
| 老王 | 男 | 35 |
这三个范式是在设计关系数据库时最基本的范式，遵循这三个范式可以减少数据冗余，提高数据的完整性和一致性。但是，在实际的数据库设计中，有时为了追求查询性能会适当的违反这些范式，引入一定的数据冗余，这种做法也是可以接受的。
最后说个事
公号算法变了，为防止看不到我的更新
大家帮忙加个星标
点击上方的公众号卡片
再点右上角三个点
就能看到设为星标
算我跪下来求你们
往期精选：
MySQL 主从复制，值得收藏！
微信，看看你的另一半跟谁聊天频繁！
让你的微信“拍一拍”有趣且不失风度
微信年度账单来了，不敢看！
张万林，下雪了……我用编程带你看场纷飞大雪
还在使用默认的微信图标？赶紧换个吧！
我的微信和你们的不一样！？
