数据库优化之数据库设计

Posted 2021-05-01 我的笔记网

1、数据库表的设计范式

i. 第一范式：数据库表中的所有字段都是单一属性（基本的数据类型整数，浮点数，字符串等），不可再分的。这个单一属性是由基本的数据类型所构成的。也就是说数据库中的表都是二维的。

上面这就是一张就是由行和列组成的。

第一张表就是符合我的需求的，它是一张由行和列组成的，但是第二张表就含有一个复合信息的就是【用户信息这一栏】，这样的设计就是不复合我们的需求的。在大多数数据库管理系统中，我们都是使用第一种建表的。

ii. 第二范式：数据库表中不存在非关键字段对任何一候选关键字段的部分函数依赖。部分函数依赖是指存在组合关键字中的某一关键字决定非关键字的情况。也就是说所有单关键字段的表，都符合第二范式

商品名称	供应商	价格	重量		分类
哇哈哈	一厂	1.75元	25G	66666	饮料
哇哈哈	二厂	1.75元	25G	88888	饮料

  由于相同的商品是由多个供应商来进行供应的，比如说我们的哇哈哈，他可以由一厂来供应也可以由二厂来供应。在这张表中，我们就不能以哇哈哈来作为商品名称来作为关键字，而要以商品名称+供应商（就是说需要用组合关键字来唯一标识）。也就是说商品名称+供应商是一组组合关键字。上面这张表中也存在部分关系依赖

    正确的建表如下：

商品ID	商品名称	价格	供应商ID	重量	分类
1	哇哈哈	1.75元	1	25G	饮料

 

供应商ID	供应商名称
1	供应商1	66666666
2	供应商2	88888888

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

商品名称	价格	商品描述	重量	有效期	分类	分类描述
可乐	3.00		250ml	2017.12.08	饮料	碳酸饮料
苹果	8.00		150G		水果	水果

  从上面的表我们可以看出，商品名称决定了商品的分类，商品的分类决定了分类描述，也就是说分类描述对商品名称来说有着传递性的依赖关系，这样来说就是不符合第三范式要求的。

  这样会存在大量的数据冗余，而且冗余的程度比第二范式还要严重

            iv. BC范式：是定义在第三范式的基础之上的，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BC范式。也就是说如果是复合关键字，则复合关键字之间也不能存在函数依赖关系。

供应商	商品ID	供应商联系人	商品数量
供应商1	1	张三	10
供应商1	2	李四	20
供应商2	1	王五	20

假设：一个联系人只能受雇于一个供应商，每家供应商可以供应多个商品，则存在一下决定关系(依赖关系)：

供应商+商品ID  可以决定  联系人  商品数量

联系人+商品ID  可以决定  供应商  商品数量

存在下列关系因此不符合我们的BC范式：

供应商  决定了  供应商联系人

供应商联系人   决定了  供应商    并且存在数据操作异常以及数据冗余

 

到此我们在需求中整个设计，但是我们的需求是不断的变化的，所以我们在做设计的时候也要不断的改变

2、数据库维护和优化的工作

i. 维护数据字典：数据字典是在我们应用维护中非常重要的一个，因为当开发一些十分庞大的项目的时候，几百上千个字段的时候，我们不可能把每个表和每个字段的含义都背着，特别是一些状态字段(比如说1：男  2：女 这样)，我们在维护过程中就需要去借助数据字典。

ii. 维护引擎：因为表的结构不断的变化，表中的数据不断的变化，以及业务上的查询的数据不断的变化，所以我们就必须对表中的索引进行不断的优化，以达到最完美的地步。

iii. 维护表结构：在我们的数据不断的变化，有的时候我们需要维护我么的表结构，或许在最开始的时候，我们的表结构是很完美的，但是因为增加了很多的数据，以及业务上面的需求，我们不得不改变表结构，所以我们也要维护我们的表结构。

iv. 拆分数据表：在随着我们的数据不断的增长，超过一定的数据程度的时候，会降低我们的查询效率，这个时候我们就要考虑对数据表进行拆分。数据表的拆分一般分为两种，水平拆分和垂直拆分

3、数据库如何维护数据字典

i. 使用第三方工具来对数据字典来进行维护

ii. 利用数据库本身自带的备注来维护数据字典

4、数据库如何维护引擎

i. 如何选择合适的列(某个字段)来建立索引

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

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

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

ii.注意事项

  1. 索引不是越多越好。过多的索引不但会降低写的效率，还好降低读的效率

 我们每写一条数据，都需要对这些索引进行维护，重新建立这些索引的统计信息，这肯定会对写的效率有一定程度上面的降低；SQL优化器会对我们的索引信息和统计信息来选择适合我们的SQL语句的索引，如果对于一个SQL来说有太多的索引的话，SQL优化器会在多个合适的索引中进行选择。选择的过程就会降低我们的查询效率。

2. 定期维护索引碎片

 所谓的索引碎片就是指我们在对数据库信息操作之后所留下的残留文件，一般很小。就好比我们电脑或手机，卸载完应用程序之后多多少少会有一些残留的文件在电脑或手机上面。这些碎片也会占有空间，所以我们也要时常的维护

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

5、数据库合适的操作

i. 注意事项

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

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

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

pt-online-schema-change：这种工具在变更数据库表的时候

建立一个临时表将表内容复制出来进行重命名，达到减少线上的数据柱塞来进行表结构的变更，前提是这个表中没有触发器。

2. 及时的维护数据字典

3. 控制表的宽度和大小

    ii. 数据库中适合的操作

            1. 批量操作和逐条操作

    在数据库中比较使用批量操作，在程序业务上面比较适合逐条操作

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

    使用了select*这样的操作，我们查询出了大量的不需要的字段内容，降低了我们的查询效率

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

    自定义函数虽然说很方便，但是大量的使用自定义函数的话，会对我们的索引造成影响。如果说使用了函数，这个列中的索引就会不起作用的。

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