如何设计一个关系型数据库（模块划分能力以及对数据库的了解）

如何设计一个关系型数据库（模块划分能力以及对数据库的了解）

 

声明：以下内容均来自慕课网翔仔老师剑指office课程口述，经个人逐字逐句听入敲写而成，如果有问题的话请通知我删除，谢谢

数据库最主要的功能是存储我们的数据，因此会有一个存储模块来存储数据，类似OS文件系统

光有存储还不够，还需要组织运用数据，因此需要程序实例，用逻辑结构映射物理结构，在程序中提供获取和管理数据的方式还有必要的问题追踪机制

细分程序的模块：

首先要对数据的格式以及文件的分割进行统一的管理，即把物理数据通过逻辑的形式组织表现出来，这就涉及到了程序的存储管理模块；（如何优化存储效能：处理数据不可能在磁盘上做，而是加载到程序空间所在的内存中去做，而磁盘IO速率往往是程序执行速度的主要瓶颈，为了执行效率，需要尽可能的减少IO，一次IO读取单行数据和多行的数据花费的时间并没有多少的区别，一次性读取多行数据以提升IO的效能，所以行就失去了它的意义，数据库把逻辑存储单位以块和页来表示，每个块表示会存放多行数据，这样读取的时候会把多个块一起加载到内存中）

未来更快更好的优化我们的程序，所以引入缓存机制，将取出的数据块放入缓存中，下次使用时直接从内存中返回，而不用IO，（需要补充的是，刚刚提到的一次性加载多个块或者页，这些里面包含的数据有相当的一部分不是我们本次查询需要的行，根据，一旦某行数据被访问了，那么它附近的数据也极有可能被访问的经验，咱们缓存的非本次数据也起到优化访问效率的作用，举例：读取A的时候会一起读取到ABC，那么下次需要B的时候会更方便，管理缓存也有许多的方法）

接下来，在我们提供给外界指令来操作数据库，及我们可读的SQL语言，那我们就需要一个SQL解析模块，来将sql语句编译解析成机器可读的语言（为了进一步提升SQL执行效率该怎么办，老办法，还是将我们的SQL语句缓存到缓存中，编译好的SQL方便下次使用的时候直接解析就行了）

大家可以注意都我们在设计程序的时候要先考虑实现功能然后在考虑优化，周而复始。还要补充一点，缓存不宜过大，且算法里要有淘汰机制，淘汰掉一些不常用的数据

此外咱们做的SQL参数需要记录下来，方便我们做数据库的主从同步或者灾难恢复，因此，我们就需要有日志管理办法，去对我们的操作做记录

再者，我们需要给用户管理数据的私密空间，即权限划分，（通常是DBA该做的事情）

设计系统的时候除了考虑正常的功能还要考虑异常的情况，这时候就需要映入容灾机制，当我们数据库挂了需要怎么回复，恢复到什么程度，这些都需要设计。

接下来，为了进一步提升查询数据的速度以及让数据库支持并发，还需要引入最需要突出数据库特点的两个模块，索引管理和锁管理模块，

 

 

数据库开发其实跟我们做的项目一样，考虑设计的模块也都类似的，其架构堪称经典，所以对我们的程序开发和学习，很有借鉴的意义。

 

 

索引管理：

1）为什么要使用索引

咱们先对查询数据的方式做一个调研，最简单方式对数据进行查询，那就是全表扫描，将整张表的数据全部或分批次记载到内存中，刚刚我们提到存储的最小单位是块或者列，他们是由多行数据组成的，我们将这些块都加载进来，逐个块去轮寻，找到我们要的目标并返回，这种方式普遍认为会比较慢的，当数据量少的时候适用，数据量大的时候不适用，因此很多情况下我们要避免全表扫描的发生，所以我们需要映入更高效的机制 索引，它的灵感来自字典，在字典中只要我们把一些关键信息组织起来，比如说偏旁部首这些，查询的时候依据这些指引，就能查询到我们想要的信息，很快便能查到我们要查的字了，这些关键信息和查找的方式便组成了我们的索引，通过索引来大幅度提升查询速度。

2）有什么信息能成为索引

能把该记录限定到一定范围内的字段，就是刚刚说的关键信息，主键便是一个很好的切入点，唯一键和其他普通建都可以

3）索引的逻辑结构

有了关键字还不行，关键是要将它以什么样的逻辑结构组织起来才能让我们检索的更高效，即我们现在来分析的数据结构。这里就要想一些让查询变得高效的数据结构了，最简单的便是二叉查找树，复杂点的是它的变种平衡二叉树，红黑树以及B-Tree以及B+-Tree还有Hash结构，咱们MySQL索引主要通过B+-Tree来实现的

4）密集索引和稀疏索引的区别

密集索引：文件中的每个搜索码值都对应一个索引值

稀疏索引：文件只为索引码的某些值建立索引项

密集索引的定义是叶子节点保存的不只是键值，还保存了位于同一行记录里的其他列的信息，由于密集索引决定了表的物理排列顺序，一个表只有一个物理排列顺序，所以一个表只能创建一个密集索引

稀疏索引：叶子节点仅保存了键位信息以及该行数据的地址，有的稀疏索引仅保存了键位信息及其主键，那么定位到叶子节点之后任然需要地址或者主键信息进一步定位到数据

 

 

对MySQL做具体分析：

它主要有两种存储引擎，mysam，innodb，这两种是主流。

mysam：不管是主键索引，唯一键索引还是普通索引都是稀疏索引

innodb：有且只有一个密集索引

innodb密集索引的选取规则：

• 如果一个主键被定义，那么这个主键作为密集索引
• 如果没有定义主键，那么该表的第一个唯一非空索引作为密集索引·
• 如果没有定义主键也没有唯一非空索引，innodb内部会生成一个隐藏主键（密集索引），这个隐藏属性是一个6字节的列，列的值会随之数据插入而自增，也就是说innodb必须有一个主键，该主键必须作为唯一的密集索引而存在
• 为什么一定要有主键索引呢，因为有一条需要注意的规定，非主键索引也就是我们稀疏索引的叶子节点并不存储行数据的物理地址，而是存储该行地址的主键值，所以非主键索引包含了两次查找，一次是查找次级索引自身，然后再查找主键

innodb使用的是密集索引，将主键组织到一棵B+树中，行数据就存储在叶子节点上，因为innodb的主键索引和对应的数据是保存在一个文件中的，所以检索的时候，在加载叶子节点的主键进入内存的同时，也加载了对应的数据，即若使用value=14这样的条件查询主键，按照B+树的查询算法即可查找到对应的叶子节点并获得对应的行数据，若对稀疏索引进行条件筛选，则需要异步在稀疏索引中检索B+树，比如说检索Elison就能定位到主键信息，然后取到主键信息之后还需要第二步，使用主键value=14在B+树中再一次行一次B+树的检索操作，到达叶子节点获取整行的数据

mysam使用的是稀疏索引，稀疏索引的两颗B+树看上去没有什么不同，节点的结构完全一致，只是存储的内容不一样而已，主键索引B+树的这个节点存储了主键，辅助键B+树存储了辅助键，表数据存储在独立的地方，就是索引跟它的数据是分开存储的，这两个B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说这俩个键没有任何的差别，通过辅助键无需访问主键