如何维护索引

如何选择合适的列建立索引

1、出现在where从句 group by 从句 order by 从句中的列

2、可选择性高的列要放到索引的前面

3、索引中不要包括太长的数据类型

注意事项

1、索引并不是越多越好，过多的索引不但会降低写效率而且会降低读的效率

2、定期维护索引碎片

3、在sql语句中不要使用强制索引关键字

如何维护表结构

1、使用在线变更表结构的工具

mysql5.6之后本身支持在线表结构的变更

2、同时对数据字典进行维护

3、控制表的宽度和大小

数据库中适合的操作

1、批量操作VS逐条操作

2、禁止使用select * 这样的查询

3、控制使用用户自定义函数

4、不要使用数据库中的全文索引

表的垂直拆分

为了控制表的宽度可以进行表的垂直拆分；

1、经常一起查询的列放在一起；

2、text,blob等大字段拆分出到附加表中

表的水平拆分

为了控制表的大小可以进行表的水平拆分

hash key 取模 等分表

反范式化

所谓反范式化就是为了性能和读取效率的考虑而适当的对第三范式的要求进行违反，而允许存在的少量的数据冗余

反范式化就是使用空间来换取时间；

为什么要反范式化

1、减少表的关联数量

2、增加数据的读取效率

3、反范式化一定要适度

如何选择主键

1、区分业务主键和数据库主键

业务主键用于标识业务数据，进行表与表之间的关联；

数据库主键为了优化数据存储（Innodb会生成6个字节的隐含主键）

2、根据数据库的类型，考虑主键是否要顺序增长

有些数据库是按主键的顺序逻辑存储的

3、主键的字段类型所占空间要尽可能的小；

对于使用聚集索引方式存储的表，每个索引后都会附件主键信息；

避免使用外键约束

1、降低数据导入的效率

2、增加维护成本

3、虽然不建议使用外键约束，但是相关联的列上一定要建立索引

避免使用触发器

1、降低数据导入的效率

2、可能会出现意想不到的数据异常

3、使业务逻辑变的复杂

关于预留字段

1、无法准确的知道预留字段的类型

2、无法准确的知道预留字段所存储的内容

3、后期维护预留字段所要的成本，同增加一个字段所需要的成本是相同的

4、严禁使用预留字段

表及字段的命名规则

1、可读性原则

使用大写和小写的格式化的库对象名字以获取良好的可读性；

使用CustAddress 而不是customeraddress来提高可读性

2、表意性原则

对象的名字应该能够描述它所标识的对象

如：对于表，表的名称应该能体现表中存储的数据内容；

对于存储过程，存储过程名称应该能够体现存储过程的功能；

3、长名原则

尽可能少使用或者不使用缩写，适用于数据（DATABASE）名之外的任一对象；

字段类型的选择原则

1、在数据进行比较（查询条件、join条件及排序）操作时：同样的数据，字符处理往往比数字处理慢

2、在数据库中，数据处理以页为单位，列的长度越小，利于性能提升

char和varchar如何选择

1、如果列中要存储的数据长度差不多是一致的，则应该考虑用char; 否则应该考虑用varchar；

2、如果列中的最大数据长度小于50byte，则一般也考虑用char；

3、一般不宜定义大于50byte的char类型列；

decinal与float如何选择

1、decimal用于存储精确数据，而flot只能用于存储非精度数据，故精确数据只能选择用decimal类型；

2、由于flot的存储空间开销一般比decimal小，故非精确数据优先选择flot类型

时间类型如何存储

1、使用int来存储时间字段的优缺点：

优点：字段长度比datetime小

缺点：使用不方便，要进行函数转换

限制：只能存储到2038-1-19 11:14:07

2、需要存储的时间颗粒

年 月 日 时 分 秒 周

表及字段的命名规则

1、可读性原则

使用大写和小写的格式化的库对象名字以获取良好的可读性；

使用CustAddress 而不是customeraddress来提高可读性

2、表意性原则

对象的名字应该能够描述它所标识的对象

如：对于表，表的名称应该能体现表中存储的数据内容；

对于存储过程，存储过程名称应该能够体现存储过程的功能；

3、长名原则

尽可能少使用或者不使用缩写，适用于数据（DATABASE）名之外的任一对象；

字段类型的选择原则

1、当一个列可以选择多种数据类型时，应该优先考虑数字类型，其实是日期或二进制类型，最后是字符串类型。

2、对相同级别的数据类型，应该优先选择占用空间小的数据类型

3、在数据库进行比较（查询条件、JOIN条件及排序）操作时：

同样的数据，字符处理往往比数字处理慢；

4、在数据库中，数据处理以页为单位，列的长度越小，利于性能提升；

Boyce.Codd范式（BCNF）

定义：在第三范式的基础之上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则附合BC范式；

也就是说如果是复合关键字，则复合关键字之间也不能存在函数依赖关系；

第二范式（2NF）

存在的问题：

1、插入异常

2、删除异常

3、更新异常

4、数据冗余

第三范式（3NF）

定义： 第三范式是在第二范式的基础之前定义的，如果数据表中不存在非关键字段，对任意候选关键字段的传递函数依赖则符合第三范式；

（商品名称）->（分类）-> （分类描述）

也就是说存在非关键字段 '分类描述'对关键字段'商品名称'的传递函数依赖；

存在问题：

（分类、分类描述）对于每个商品都会进行记录，所以存在着数据冗余。同时也还存在数据的插入，更新及删除异常

第一范式（1NF）

定义：数据库表中所有字段都是单一属性，不可再分的；

第一范式要求数据库的表都是二维表

第二范式（2NF）

定义：数据库的表中不存在非关键字段对仁义候选关键字段的部分函数依赖；

数据库操作异常

数据库建立的1步骤

表的水平拆分

表的垂直拆分

字段类型选择原则

字段类型的定义

ＭySQL常用存储引擎