一、关系型数据库三范式
1.第一范式：
数据库表的字段要具有原子性，不可以继续拆分，一般根据实际需求来去决定
| id | name | age | adress |
|---|---|---|---|
| 1 | 张三 | 19 | 北京市朝阳区 |
如上面的表，每一个字段都是不可拆分的
2.第二范式：
建立在第一范式的基础上，每一列数据必须可被唯一的区分，依赖于主键，每一张表至少要有一个主键
满足第一范式
字段可被唯一区分，至少有一个主键（标识数据的唯一性）
依赖于主键
| id | name | age | sheng | shi |
|---|---|---|---|---|
| 1 | 安徽省 | 安庆市 | ||
| 主键 | 满足第一范式的情况下 | 通过上表adress区分 |
3.第三范式：
建立在第二范式的基础之上，一般应用于设计多表关系中，要求一个数据表中不包含已在其他表中已包含的非主键字段，因为会出现冗余，表的信息如果能被推导出来就不应该单独设计一个字段来存储，可以使用外键进行关联， 而不是将另一张表中的非主键属性直接写在当前表中
商品表
| id | name | price | type |
|---|---|---|---|
| 1 | 西服 | 1000 | 男装 |
| 2 | 连衣裙 | 200 | 女装 |
类别表
| id | typename |
|---|---|
| 1 | 男装 |
| 2 | 女装 |
上述就显得冗余，根据第三范式应该改为
| id | name | price | type_id |
|---|---|---|---|
| 1 | 西服 | 1000 | 1 |
| 2 | 连衣裙 | 200 | 2 |
在做优化时，
做 反三范式 的设计：允许部分字段冗余
| id | name | price | type_id | 经常要查的东西 |
|---|---|---|---|---|
| 1 | 西服 | 1000 | 1 | 男装等描述 |
| 2 | 连衣裙 | 200 | 2 | 女装等描述 |
三范式：只是我们设计表时的一个参考规则，实际表的设计要根据实际业务来去设计
二、数据库优化
1.库和表结构优化
分库分表
当单个库或者表中的数据量大时 数据库的性能会变慢
垂直拆分
1.垂直拆分表
当一个表中的数据量比较大字段比较多时，创建一个附属表，将表中不常用的字段存入附属表，通过创建外键进行关联
| id | 姓名 | 性别 | 年龄 | 邮箱 | 手机号 | 电话 | 住址 |
|---|---|---|---|---|---|---|---|
字段名较多和数据量较大，按照列 拆分表，创建附属表
2.垂直拆分库
根据不同的业务需求，将不同的表放入不同的库中，一般会放到多个服务器上（放在同一个服务器上对优化起到的作用不大）
相同类别的表放在同一个库 数据量大，放在多个服务器上
水平拆分
1.水平分库分表 （只有水平拆分表）
单表数据量太大 将数据水平拆分成多个表，多个表组合在一起才能组成一个完成的数据
将拆分的表放到不同的库中，一张表放到一个库中去
按照行来拆分，结构一模一样
2.水平拆分面临的问题：
主键如何保证唯一性（主键可能重复）
解决方式：
1.制定每张表的id取值范围
2.通过时间或者地理位置
3.通过趋势递增 雪花算法
水平分库 会面临 多表查询会受到影响 事物也会受到影响
解决方法：
目前没有人能解决这些问题，我们可以使用开源的框架产品来解决
但是不同的开源产品，所解决的问题也不相同，所以根据自己的需求来去选择
2.架构优化：
主从复制
(读写分离)
添加缓存
一般使用非关系数据库做为缓存数据库 将数据存到内存中
写数据写到主数据库，从从数据库读取数据，从数据库读取主数据库中的信息，然后从库读取到的信息执行写操作，然后就可以从从库中读取数据
并发量大，读写频率高，这时
一般将热点数据，访问量大的放在缓存服务器中
添加缓存
直接从缓存服务器中拿，减轻服务器压力
3.sql语句的优化：
1.允许部分字段冗余，使用逻辑外检避免使用物理外键
2.添加索引：给查询频繁的条件添加索引，使用索引最左原则
*3.查询时 select 后面不使用*
4.sql关键字尽量大写
5.使用关联查询替代嵌套子查询
6.使用where条件过滤 避免全表查询
7.Update修改时，避免修改索引字段所在的列
避免修改where后面字段
8.减少数据库的查询的次数
