1.数据库结构优化
数据库结构优化的目的：
减少数据冗余
尽量避免数据维护中出现更新，插入和删除异常
插入异常：如果表中的某个实体随着另一个实体而存在
更新异常：如果更改表中的某个实体的单独属性时，需要对多行进行更新
删除异常：如果删除表中的某一实体则会导致其他实体的消失
节约数据存储空间
提高查询效率
2.数据库结构设计的步骤
需求分析：全面了解产品设计的存储需求、数据处理需求、数据的安全性和完整性
逻辑设计：设计数据的逻辑存储结构，数据实体之间的逻辑关系，解决数据冗余和数据维护异常
物理设计：根据所使用的数据库特点进行表结构设计
维护优化：根据实际情况对索引、存储结构等进行优化
数据库设计范式：
数据库设计的第一范式：
数据库表中的所有字段都只具有单一属性
单一属性的列是由基本的数据类型所构成的
设计出来的表都是简单的二维表
数据库设计的第二范式：
需要一个表中只具有一个业务主键，也就是说符合第二范式的表中不能存在非主键列对只对部分主键的依赖关系
数据库设计的第三范式：
指每一个非主属性即不部分依赖于也不传递依赖于业务主键，也就是在第二范式的基础上消除了非主属性对主键的传递依赖
什么叫做反范式化设计：
反范式化是针对范式化而言的，所谓的反范式化就是为了性能和读取效率的考虑而适当的对数据库设计范式的要求进行违反，而允许存在少量的数据冗余，换句话来说反范式化就是使用空间来换取时间。
范式化设计的优点：
可以尽量的减少数据冗余（数据表更新快体积小）
范式化的更新操作比反范式化更快
范式化的表通常比反范式化更小
范式化设计的缺点：
对于查询需要对多个表进行关联
更难进行索引优化
反范式化设计的优点：
可以减少表的关联
可以更好的进行索引优化
反范式化设计的缺点：
存在数据冗余及数据维护异常
对数据的修改需要更多的成本
3.MySQL数据库的物理设计
物理设计涉及的内容
定义数据库、表及字段的命名规范
命名遵守可读性原则
命名遵守表意性原则
命名遵守长名原则
选择合适的存储引擎
推荐Innodb
为表中的字段选择合适的数据类型
当一个类可以选择多种数据类型时，应该优先考虑数字类型，其次是日期或者二进制类型，最后是字符类型。对于相同级别的数据类型，应该优先选择占用空间小的数据类型。
如何选择varchar和char类型：
varchar类型的存储特点：
varchar用于存储变长字符串，只占用必要的存储空间
列的最大长度小于255则只占用一个额外字节用于记录字符串长度
列的最大长度大于255则要占用两个额外字节用于记录字符串长度
varchar长度的选择问题：
使用最小的符合需求的长度（从业务上了解）
varchar（5）和varchar（200）存储同一个字符串的性能不同
varchar的适合场景：
字符串列的最大长度比平均长度大很多
字符串列很少被更新
使用了多字节字符集存储字符串
char类型的存储特点：
char类型是定长的
字符串存储在char类型的列中会删除末尾的空格
char类型的最大宽度为255
char类型的适用场景：
char类型适合存储所长度近似的值
char类型适合存储短字符串
char类型适合存储经常更新的字符串列
如何存储日期类型：
DATATIME类型：
以YYYY-MM-DD HH:MM:SS[.fraction]格式存储日期时间
datetime = YYYY-MM-DD HH:MM:SS
datetime = YYYY-MM-DD HH:MM:SS.fraction
DATATIME类型与时区无关，占用8个字节的存储空间
时间范围 1000-01-01 00：00：00 到9999-12-31 23：59：59
TIMESTAMP类型（时间戳）：
存储了由格林尼治时间1970年1月1日到当前时间的秒数
以YYYY-MM-DD HH:MM:SS.[.fraction]的格式显示，占用4个字节
时间范围1970-01-01 到 2038-01-19
timestamp类型显示依赖于所指定的时区
在行的数据修改时可以自动修改timestamp列的值
date类型和time类型：
把日期部分存储为字符串（至少要8个字）
使用int类型来存储（4字节）
使用datetime类型来存储（8个字节）
date类型用于保存1000-01-01到9999-12-31之间的日期
time类型用于存储时间数据，格式为HH:MM:SS
date类型的优点：
占用的字节数比使用字符串、datetime、int存储要少，使用date类型只需要3个字节
使用Date类型还可以利用日期时间函数进行日期之间的计算
存储日期时间数据的注意事项
不要使用字符串类型来存储日期时间数据
使用int存储日期时间不如使用timestamp类型
建立数据库结构
