mysql数据库优化

数据库结构优化目的：

1、减少数据冗余

2、尽量避免数据维护中出现更新，插入和删除异常

插入异常：如果表中的某个实体随着另一个实体而存在

更新异常：如果更改表中的某个实体的单独属性时，需要对多行进行更新

删除异常：如果删除表中的某个实体会导致其他实体的消失

3、节约数据存储空间

4、提高查询效率

数据库结构设计的步骤：

1、需求分析：全面了解产品设计的存储需求，存储需求，数据处理需求，数据的安全性和完整性

2、逻辑设计：设计数据的逻辑存储结构，数据实体之间的逻辑关系，解决数据冗余和数据维护异常

3、物理设计：根据所使用的数据库特点进行表结构设计

4、维护优化：根据实际情况对索引、存储结构等进行优化

数据库设计的范式：设计出没有数据冗余和数据维护异常的数据库结构

三范式：第一范式：数据库表中所有字段都具有单一属性，不可再分割；单一属性的列是由基本的数据类型所

构成；设计出来的表都是简单的二维表

第二范式：一个表中只有一个业务主键 （

一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的部分）

第三范式：

目标是确保每列都和主键列直接相关,而不是间接相关(另外非主键列必须直接依赖于主键，不能存在传递依赖).

第一范式:确保每列的原子性(强调的是列的原子性，即列不能够再分成其他几列).
    如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式.
    例如:顾客表(姓名、编号、地址、……)其中"地址"列还可以细分为国家、省、市、区等。
 
 
第二范式:在第一范式的基础上更进一层,目标是确保表中的每列都和主键相关(一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的部分)
    如果一个关系满足第一范式,并且除了主键以外的其它列,都依赖于该主键,则满足第二范式.
    例如:订单表(订单编号、产品编号、定购日期、价格、……)，"订单编号"为主键，"产品编号"和主键列没有直接的关系，即"产品编号"列不依赖于主键列，应删除该列。
 
第三范式:在第二范式的基础上更进一层,目标是确保每列都和主键列直接相关,而不是间接相关(另外非主键列必须直接依赖于主键，不能存在传递依赖).
    如果一个关系满足第二范式,并且除了主键以外的其它列都不依赖于主键列,则满足第三范式.
    为了理解第三范式，需要根据Armstrong公里之一定义传递依赖。假设A、B和C是关系R的三个属性，如果A-〉B且B-〉C，则从这些函数依赖中，可以得出A-〉C，如上所述，
依赖A-〉C是传递依赖。
    例如:订单表(订单编号，定购日期，顾客编号，顾客姓名，……)，初看该表没有问题，满足第二范式，每列都和主键列"订单编号"相关，再细看你会发现"顾客姓名"和"顾客
编号"相关，"顾客编号"和"订单编号"又相关，最后经过传递依赖，"顾客姓名"也和"订单编号"相关。为了满足第三范式，应去掉"顾客姓名"列，放入客户表中。

反范式化：用存储空间换取更高的效率

物理设计：为表中的字段选择合适的数据类型

当一个列可以选择多种数据类型时，应该优先考虑数字类型，其次是日期或二进制类型

，最后是字符类型。对于相同级别的数据类型，应该优先选择占用空间小的数据类型

float 不精确，double不精准，decimal精准（decimal比bigint大，占用九个字节）

varchar变长，小于255，会有一个字节记录长度，大于255会有两字节记录长度，适合存储变化小的列

char定长，分配好长度，适合存储长度相差不多或定长，存储较短字符，经常会更新字符串(防止产生更多的存储碎片，可以获得更好的I/O性能)

timestamp依赖时区，修改时会更改，datetime不依赖时区