【数据库范式】

文章介绍了数据库设计中的范式理论,包括第一范式到第三范式,强调了范式在减少数据冗余和保证数据完整性方面的作用,同时也指出其可能导致的性能问题。反范式设计则是在特定业务场景下,为提高查询性能而允许适当的数据冗余。文章还提及了MySQL的使用原则和设计规范,如避免大事务和大SQL以优化性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

范式与反范式

优秀的库表设计是高性能数据库的基础。如何才能设计出高性能的库表结构呢?这里必须要提到数据库范式。范式是基础规范,反范式是针对性设计。

范式

范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法。数据库的设计范式是数据库设计所需要满足的规范。只有理解数据库的设计范式,才能设计出高效率、优雅的数据库,否则可能会设计出低效的库表结构。

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,还又称完美范式)。

满足最低要求的叫第一范式,简称 1NF。在第一范式基础上进一步满足一些要求的为第二范式,简称 2NF。其余依此类推。各种范式呈递次规范,越高的范式数据库冗余越小。通常所用到的只是前三个范式,即:第一范式(1NF),第二范式(2NF),第三范式(3NF)。

第一范式

第一范式无重复的列,表中的每一列都是拆分的基本数据项,即列不能够再拆分成其他几列,强调的是列的原子性.。

如果在实际场景中,一个联系人有家庭电话和公司电话,那么以“姓名、性别、电话”为表头的表结构就没有达到 1NF。要符合 1NF 我们只需把电话列拆分,让表头变为姓名、性别、家庭电话、公司电话即可。

第二范式

第二范式属性完全依赖于主键,首先要满足它符合 1NF,另外还需要包含两部分内容:

  • 表必须有一个主键;

  • 没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。即要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。

第三范式

第三范式属性不传递依赖于其他非主属性,首先需要满足 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。

第二范式和第三范式的区别

  • 第二范式:非主键列是否依赖主键(包括一列通过某一列间接依赖主键),要是有依赖关系就是第二范式;

  • 第三范式:非主键列是否直接依赖主键,不能是那种通过传递关系的依赖。要是符合这种依赖关系就是第三范式。

通过对前三个范式的了解,我们知道 3NF 是 2NF 的子集,2NF 是 1NF 的子集。

设计符合 2NF 的表

接下来以订单信息表为例,讲述如何设计一个符合 2NF 的表,首先,我们看原始的订单信息表,如下图所示。

第二范式和第三范式的区别

  • 第二范式:非主键列是否依赖主键(包括一列通过某一列间接依赖主键),要是有依赖关系就是第二范式;

  • 第三范式:非主键列是否直接依赖主键,不能是那种通过传递关系的依赖。要是符合这种依赖关系就是第三范式。

通过对前三个范式的了解,我们知道 3NF 是 2NF 的子集,2NF 是 1NF 的子集。

范式优缺点

经过前面的讲解和案例分析可知范式具备以下优点:

  • 避免数据冗余,减少维护数据完整性的麻烦;

  • 减少数据库的空间;

  • 数据变更速度快。

同时,也有如下缺点:

  • 按照范式的规范设计的表,等级越高的范式设计出来的表数量越多。

  • 获取数据时,表关联过多,性能较差。

表的数量越多,查询所需要的时间越多。也就是说所用的范式越高,对数据操作的性能越低。  

反范式

范式是普适的规则,满足大多数的业务场景的需求。对于一些特殊的业务场景,范式设计的表,无法满足性能的需求。此时,就需要根据业务场景,在范式的基础之上进行灵活设计,也就是反范式设计。

反范式设计主要从三方面考虑:

  • 业务场景;

  • 相应时间;

  • 字段冗余。

反范式设计就是用空间来换取时间,提高业务场景的响应时间,减少多表关联。主要的优点如下。

  • 允许适当的数据冗余,业务场景中需要的数据几乎都可以在一张表上显示,避免关联;

  • 可以设计有效的索引。

范式与反范式异同

范式化模型:

  • 数据没有冗余,更新容易;

  • 当表的数量比较多,查询数据需要多表关联时,会导致查询性能低下。

反范式化模型:

  • 冗余将带来很好的读取性能,因为不需要 join 很多表;

  • 虽然需要维护冗余数据,但是对磁盘空间的消耗是可以接受的。

MySQL 使用原则和设计规范

讲完范式,接下来我们看看 MySQL 使用中的一些使用原则和设计规范。

MySQL 虽然具有很多特性并提供了很多功能,但是有些特性会严重影响它的性能,比如,在数据库里进行计算,写大事务、大 SQL、存储大字段等。

想要发挥 MySQL 的最佳性能,需要遵循 3 个基本使用原则。

  1. 首先是需要让 MySQL 回归存储的基本职能:MySQL 数据库只用于数据的存储,不进行数据的复杂计算,不承载业务逻辑,确保存储和计算分离;

  2. 其次是查询数据时,尽量单表查询,减少跨库查询和多表关联;

  3. 还有就是要杜绝大事务、大 SQL、大批量、大字段等一系列性能杀手

  • 大事务,运行步骤较多,涉及的表和字段较多,容易造成资源的争抢,甚至形成死锁。一旦事务回滚,会导致资源占用时间过长。

  • 大 SQL,复杂的 SQL 意味着过多的表的关联,MySQL 数据库处理关联超过 3 张表以上的 SQL 时,占用资源多,性能低下。

  • 大批量,意味着多条 SQL 一次性执行完成,必须确保进行充分的测试,并且在业务低峰时段或者非业务时段执行。

  • 大字段,blob、text 等大字段,尽量少用。必须要用时,尽量与主业务表分离,减少对这类字段的检索和更新。

下面具体讲解数据库的基本设置规则:

  1. 必须指定默认存储引擎为 InnoDB,并且禁用 MyISAM 存储引擎,随着 MySQL 8.0 版本的发布,所有的数据字典表都已经转换成了 InnoDB,MyISAM 存储引擎已成为了历史。

  2. 默认字符集 UTF8mb4,以前版本的 UTF8 是 UTF8mb3,未包含个别特殊字符,新版本的 UTF8mb4 包含所有字符,官方强烈建议使用此字符集。

  3. 关闭区分大小写功能。设置 lower_case_tables_name=1,即可关闭区分大小写功能,即大写字母 T 和小写字母 t 一样。

这里在实践中有个小问题,如何让系统中区分大小写的库表转换为不区分大小写的库表呢?因为要修改底层数据,还是比较麻烦的,操作步骤如下。

  1. MySQL dump 导出数据库。

  2. 修改参数 lower_case_tables_name=1。

  3. 导入备份数据时,必须停止数据库,停止业务,影响非常大。

  4. 开启 per-table 表空间,开启后,每张业务表会单独创建一个独立于系统表空间的表空间,便于空间的回收,数据的迁移。

MySQL 数据库提供的功能很全面,但并不是所有的功能性能都高效。

  1. 存储过程、触发器、视图、event。为了存储计算分离,这类功能尽量在程序中实现。这些功能非常不完整,调试、排错、监控都非常困难,相关数据字典也不完善,存在潜在的风险。一般在生产数据库中,禁止使用。

  2. lob、text、enum、set。这些字段类型,在 MySQL 数据库的检索性能不高,很难使用索引进行优化。如果必须使用这些功能,一般采取特殊的结构设计,或者与程序结合使用其他的字段类型替代。比如:set 可以使用整型(0,1,2,3)、注释功能和程序的检查功能集合替代。

以上是基础规范的内容,但并不是全部,只是以点带面,进行粗略的介绍。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值