MySQL笔记4

一、范式

1.概念与意义

  范式（Normal Form）是数据库设计需遵循的规范，解决“设计随意导致后期重构困难”问题。主流有 三大范式（1NF、2NF、3NF），还有进阶的 BCNF、4NF、5NF 等，范式间是递进依赖（如 2NF 基于 1NF，3NF 基于 2NF ）。

2.第一范式（1NF）

（1）规则：字段需满足原子性（不可再拆分）

（2）示例：

   如图，学生表中“student”字段列存储的数据，明显还可拆分为姓名、性别、身高，拆分后才符合 1NF。所以应将表结构更改为下图，才符合1NF：

 （3）不满足1NF的影响：

  客户端语言和表之间无法很好的生成映射关系

  查询到数据后，需要处理数据时，还需要对其字段进行额外拆分

  插入数据时，对于第一个字段的值还需要先拼装后才能进行写入

3.第二范式（2NF）

（1）规则：满足1NF的基础上，表中所有列必须完全依赖主键（一张表只描述一类业务，无冗余关联）。

（2）示例：观察1NF中表中 course 、 score 这两列数据，跟前面的几列数据实际上依赖关系并不大，所以此时在1NF表基础上可以再次拆分一下表结构：

student 表

 course 表

score 表 

 结构优化后，之前的一张表被拆分成学生表、课程表、成绩表三张，每张表中的 id 字段作为主键，其他字段都依赖这个主键。无论在那张表中，都可以通过id主键确定其他字段的信息，每张表的业务属性都具备“唯一性”。

（3）不满足2NF的影响：

  因字段对主键存在部分依赖，会导致：数据冗余（部分信息重复存）

  更新异常（改一处需动多条）

  插入/删除异常（操作受主键关联限制，易出错）

4.第三范式（3NF）

（1）规则：满足2NF的基础上,非主键字段不传递依赖于主键（字段间独立，无间接依赖）。

（2）示例：观察2NF中 student 表，最后的两个字段 department（学生所属的院校） 和 dean （这个院系的院长 ）。一个学生的院长是谁，是取决于学生所在的院系，最后的两个字段存在依赖关系。所以进一步优化表结构：

department 表

 student 表

  将原本的学生表拆为院系表、学生表两张，学生表中则是只存储一个院系id，由院系表存储院系相关的所有数据。学生表中的每个非主键字段与其他非主键字段之间，都是相互独立的，之间不会再存在任何依赖性，所有的字段都依赖于主键。

（3）不满足3NF的影响：

  会因字段传递依赖，导致数据冗余（同信息重复存）

  更新异常（改一个值需动多条数据，易漏改）

  删除异常（删数据可能误删或残留脏数据）

  插入异常（新信息难单独插入）

  让表结构难维护、业务流程易受牵连 

5.三范式小结

1NF：确保原子性，表中每一个列数据都必须是不可再分的字段。

2NF：确保唯一性，每张表都只描述一种业务属性，一张表只描述一件事。

3NF：确保独立性，表中除主键外，每个字段之间不存在任何依赖，都是独立的。

经过三范式的设计优化后，整个库中的所有表结构，会显得更为优雅，灵活性也会更强。

6.巴斯-科德范式（BCNF）

（1）核心问题：3NF未约束联合主键字段间的依赖。若联合主键中某字段依赖另一字段，仍会导致冗余、更新异常。

（2）示例：这里我们可以通过联合主键，确定学生表中任何一个学生的信息，但是一条学生信息中的班主任（adviser），取决于学生所在的班级，因此班主任字段其实也依赖于班级字段。

  如果联合主键中的一个字段依赖于另一个字段，会造成不小的问题，使得整张表的维护性变差，因此这里需要进一步调整结构：

   原本的学生表则又被拆为了班级表、学生表两张，在学生表中只存储班级id，然后使用班级id和学生姓名两个字段作为联合主键。

 注：第三范式只要求非主键字段之间，不能存在依赖关系，但没要求联合主键中的字段不能存在依赖，因此第三范式并未考虑完善，巴斯-科德范式修正的就是这点，是对第三范式的补充及完善。

7.第四范式（4NF）

（1）核心问题：表中存在多值依赖（一个字段值由多个字段共同决定，如用户权限依赖“用户+角色” ），导致冗余和操作异常。

（2）示例：

各字段含义：

  user_name：用户名

  role：角色信息

ROOT：超级管理员角色

ADMIN：管理员角色

USER：普通用户角色

  permission：权限信息

*：超级管理员拥有的权限级别，*表示所有

BACKSTAGE：管理员拥有的权限级别，表示可操作后台

LOGIN：普通用户拥有的权限级别，表示可登录访问平台

  一个用户可以拥有多个角色，同时一个角色可以拥有多个权限，所以此时无法单独根据用户名去确定权限值，权限值必须依赖用户、角色两个字段来决定，这种一个字段的值取决于多个字段才能确定的情况，就被称为多值依赖

需进一步将表格拆分为：

users 表

roles 表

 permissions 表

users_roles 表

roles_permissions 表

  将原本的用户角色权限表，拆分成了用户表、角色表、权限表、用户角色关系表、角色权限关系表。一方面用户表、角色表、权限表中都不会有数据冗余，第二方面无论是要删除亦或新增一个角色、权限时，都不会影响其他表。后面的两张关系表，主要是为了维护用户、角色、权限三者之间的关系。

 8.第五范式

（1）规则：建立在4NF的基础上，进一步消除表中的连接依赖，直到表中的连接依赖都是主键所蕴含的。

（2）实际价值：解决“无损连接”理论问题，生产环境极少用到（场景罕见、难察觉 ），了解即可。

9.第六范式

（1）概念：域键范式，也被称之为终极范式，但目前也仅有学术机构在研究，在生产环境中实际的用途也不大

10.反范式

（1）概念：不遵循数据库范式设计的结构，称为反范式结构。

（2）优缺点：

优点

  消除数据冗余，节省存储空间；

  表结构清晰，简化 SQL 操作、减少出错。

缺点（范式级别过高时）

  数据分散到多张表，联表查询需求暴增；

  联表过多可能引发索引失效，严重拖慢业务系统性能。

（3）设计意义：因范式过高会导致性能问题，设计库表时无需 100% 遵循范式；当“破坏范式对业务的好处＞坏处”时，主动采用反范式设计。

注：不以规则为绝对标准，业务优先：能支撑业务需求、带来实际价值的设计，就是好设计。

二、数据库范式设计总结

1.范式设计的整体认知

（1） 复杂度与代价：范式级别越高，理解难度越大，为满足范式付出的设计代价（如拆分表数量、性能开销）也越大。

（2） 实际项目应用：一般项目中，满足到第三范式（3NF）或巴斯 - 科德范式（BCNF） 即可，继续追求更高范式易因过度精细设计导致整体性能下降。

（3）灵活权衡原则：控制在第三范式级别，可平衡数据冗余与性能影响；若打破范式对业务更有利，也可违背范式设计。

2.库表结构设计的合理性对比

（1）不合理设计的问题：会造成数据冗余，浪费存储空间；不便于常规 SQL 操作（如插入、删除），甚至引发异常。

（2）合理设计的好处：节省空间（内存和磁盘）；数据划分合理，数据库性能高且数据完整；结构便于维护和常规SQL操作

（3）各范式递进关系：呈包含关系，从第一范式（1NF）到域键范式（终极范式），级别越高约束越严格，如 1NF⊂2NF⊂3NF⊂BCNF⊂4NF⊂5NF⊂域键范式 。

（4）各范式概念：

  1NF（第一范式）：原子性，字段值不可再分。

  2NF（第二范式）：唯一性，字段依赖主键，每行数据描述同一业务属性。

  3NF（第三范式）：独立性，非主属性不传递依赖于主键。

  BCNF（巴斯 - 科德范式）：主键字段独立性，联合主键字段间无依赖性。

  4NF（第四范式）：多值依赖，表中一个字段值由多个字段决定。

  5NF（第五范式）：无连接依赖，表中字段数据间不存在连接依赖关系。

  域键范式（终极范式）：追求库表设计的终极完美范式，目前多处于学术研究阶段 。

三、MySQL数据库账户及授权

1.密码策略

（1）密码插件：

MySQL版本	默认密码插件	替换原因
8.0+	caching_sha2_password	mysql_native_password，解决SHAI算法安全性问题（易被破解）
5.7及以下	mysql_native_password	依赖SHAI算法，已被NIST建议弃用

关键差异： caching_sha2_password 更安全， mysql_native_password 验证速度快，但算法弱

（2）查看数据库当前密码策略的语句：show variables like '%password%';（查看所有密码相关变量）

（从上往下 ）表中每一行的意思：

  是否自动生成RSA密钥对文件

  哈希轮数，数值越大安全性越强

  RSA 私钥文件

  RSA 公钥文件

  MySQL密码过期时间,单位为天

  超时断开

  随机密码长度

  是否支持代理用户控制认证插件

  不允许用户使用最近n次使用过的密码

  修改密码时是否需要提供当前用户使用的密码，OFF不需要，ON需要

  不允许用户使用最近n天内使用过的密码

  该变量通常为空，它可能用于特定的报告或审计目的

（3）查看密码设置策略：show variables like 'validate_password%';

注：若显示为空，则表示未装插件，输入安装插件语句即可：Iinstall component 'file://component_validate_password';

（从上往下 ）表中每一行的意思：

  用于控制密码修改时字符变化比例的要求

  能将密码设置成当前用户名

  插件用于验证密码强度的字典文件路径，默认为空

  密码最小长度，默认为8，有最小值为4的限制

  密码至少要包含的小写字母和大写字母的个数

  密码至少要包含的数字个数

  密码强度检查等级

  密码必须包含的特殊字符个数

（4）密码强度检查等级解释（validate_password.policy） ：

等级	检查对象
0 或 low	检查长度6
1 或 medium	检查长度、数字、大小写、特殊字符
2 或 strong	检查长度、数字、大小写、特殊字符、字典文件

（5）设置密码强度检查的语句：

设置密码验证强度检查策略：set global validate_password.policy=等级强度;

设置至少要包含大/小写字母的个数：set global validate_password.mixed_case_count=个数;

设置至少要包含数字的个数：set global validate_password.number_count=个数;

设置至少包含特殊字符个数：set global validate_password.special_char_count=个数;

设置密码长度：set global validate_password.length=长度值;

修改后，可刷新权限，使其生效：flush privileges;

（6）修改密码的语句：

先查看 root 用户信息：select user, host, plugin from mysql.user;

再修改其密码：alter user 'root'@'来源地址' identified by '新密码';（来源地址—本地主机为localhost，远程主机为%）

最后刷新权限即可

2.登录账户管理

（1）管理原则：MySQL8遵循“先创建账户，再赋予权限”的流程，清晰分离账户创建与权限配置步骤

（2）关键操作命令：

操作目标	SQL命令	说明
查看当前用户信息	select user();	快速获取当前登录用户名
进入系统数据库	use mysql;	切换到存储用户数据的库
查看数据库表	show tables;	确认 user 表存在
查看用户表结构	desc user;	了解 user 表字段设计
查询用户核心信息	select user,host,authentication_string from user;	提取账号、允许登录主机、加密密码

3.新建登录账户

（1）新建账户的语句：create  user  '用户名'@'来源地址'  identified  by  '密码';

注：登录主机为  localhost（本地登录） 或   %（远程登录）

 退出当前账户，登录新建的账户，看是否能成功进入（只能查看有限库）：

4.账户授权

（1）账户权限管理原则：

最小化赋权：生产环境仅授予必要权限（如 select ），避免高危操作（ update / insert ）

分离角色：区分管理账号（ root ）与应用账号（业务用户）

定期清理：删除/回收闲置账户权限

（2）常见的用户权限：

（3）查看权限的语句： show grants;（查看当前用户） show grants for  '用户名'@'来源地址';（查看其他账户权限）

上例显示 haha 账户只有 usage 默认权限，即连接登录权限

（4）赋予账户权限的语句：grant 权限列表 on 数据库名.表名 to '用户名'@'来源地址' ;

 赋予 haha 账户查询mysql库的权限

查看 user 表的权限信息：

登录被赋予权限的账户，测试一下：

（5）新建远程账户（指定网段）：create user  'test1'@'网段' identified by '密码';

（6）新建高权限账户（含赋权能力）：

 但是，all 所有权限中不包含给账户赋权的权限 grant：

给 haha 账户赋予给别的账户赋权的权限：

若赋权不成功则先给 root 账户增加 system_user 权限

5.回收权限

（1）作用：取消用户已授权的数据库操作权限，细化权限管理

（2）语句：revoke  权限列表/all  on  库名.表名  from  '用户名'@'来源地址';

回收 select 权限

回收所有权限 

6.删除账户

（1）作用：彻底清除MySQL用户，连带其权限配置，清理无用账户

（2）语句：drop user '用户名'@'来源地址'; drop  user 用户名（来源地址为%，可不写来源地址）