1、为什么要进行数据库设计？

需求分析

逻辑设计ER图

物理设计

维护优化=》新建需求表，索引优化，大表拆分

需求分析（主要环节）：

1、存储数据有哪些？

日志的数据不适合存储在数据库中，首先增长量非常大，并且并不属于核心数据，如果非要存储在数据库中，要提前定义好清理规则（当数据量大时工作量也会随之增加，也影响线上的正常使用）

2、存储的数据有什么样的特点？

时效性（不具有时效性可以采取过期清理），增长量很大的数据，可以采取分库分表的方式进行存储

3、数据的生命周期？

搞清楚一些问题：

1、实体与实体之间的关系（1:1，1:N，N:N）

2、实体所包含的属性有什么，实体在存储和增长量有哪些特性

3、哪些属性或属性的组合可以唯一标识一个实体

逻辑设计ER图：

矩形：表示实体集

菱形：表示联系集

椭圆：表示实体属性

线段：表示属性连接到实体集，或实体集连接到属性

设计范式概要：

1.数据库设计范式

第一范式（1NF）：

数据表中所有字段都是单一属性，不可再分的，如：整数，浮点数，字符串等；要求数据库中的表都是二维表。

第二范式（2NF）：

表中不存在非关键字段对任意关键字段的依赖，所有单关键字段的表都符合第二范式

第三范式（3NF）：

数据表中不存在非关键字段，对任意候选关键字度的传递函数依赖则符合第三范式

Boyce.Codd范式（BCNF）：

数据库表中如果不存在任何字段对任意候选关键字段的传递函数依赖（不能存在函数依赖关系）

2.操作异常：

插入异常、更新异常、删除异常

3.数据冗余

物理设计

1、选择合适的数据库管理系统

2、定义数据库、表及字段的命名规范

3、选择合适的字段类型

4、反范式化设计（用数据冗余的空间换时间），减少表的关联数量，增加数据的读取效率，注意要适度

预留字段：

1、严禁使用预留字段，无法准确知道预留字段类型及存储内容，程序维护造成印象

维护和优化

1、维护数据字典

通过第三方工具进行维护，数据库本身的备注字段来进行维护，通过脚本导出数据字典

select a.table_name,b.TABLE_COMMENT,a.COLUMN_NAME,a.COLUMN_TYPE,a.COLUMN_COMMENTFROM infomation_schema.COLUMNS a JOIN information_schema.TABLES b ON a.table_schema=b.table_schema AND a.table_name = b.tablename where a.table_name = '表名'

2、维护索引

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

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

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

注意事项：

太多的索引会降低写和读的效率；

定期维护索引碎片；

不要使用强制索引关键字（数据量的变化，如DBA对索引进行删除，开发人员不知道，查询会出错）；

3、维护表结构

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

mysql5.5之前可以使用 pt-online-schema-change

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

2.同事对数据字段进行维护

3.控制表的宽度和大小

数据库中适合的操作

1.批量操作vs单条操作

2.禁止使用select * 这样的查询=》导致IO的浪费，查询出不使用的字段，表结构变更，对程序造成印象

3.控制使用自定义函数，使用自定义函数在数据列中的索引不起作用

4.不要使用数据库中的全文索引=》对中文支持不太好，专业的搜索引擎工具代替全文索引，增加数据执行效率

4、表瓶颈：水平和垂直拆分

表的垂直拆分

经常查询的列放到一张表中，优化了io，减少了sql复杂程度，解决了表宽度的问题

表的水平拆分

主键hash key进行拆分，解决了数据量的问题