如何设计一个关系型数据库？

两大部分

存储（文件系统（机械硬盘，固态硬盘））

程序实例

 

程序实例分为8个模块：

1.存储管理模块:将数据的逻辑关系转换为物理存储关系

2.缓存机制模块（内存来进行）:优化执行效率

3.SQL解析模块:解析SQL语句

4.日志管理模块：记录操作（分库这些）

5.权限划分模块：进行多用户管理（比如老板能看多所有员工信息，但是员工只能看到自己该看到的东西）

6.容灾机制模块：灾难恢复（异常、服务器崩溃）

7.索引管理模块：优化数据库查询

8.锁管理模块：使得数据库支持并发操作

 

为什么要使用索引

先说全表扫描:

存储的最小单位是块或页，是由多行记录组成的。（整个表就是多个块或页）我们把这些块或者页加载进去，然后每个块或者页去轮询，找到目标并返回（适用与数据比较小的）

 

索引灵感来自字典，查字典可以通过部首，拼音，查数据可以通过主键、唯一键以及普通键（我们通常说的关键字）

除此之外，我们还要将这些关键字以一种好的形式组织起来，即索引的数据结构。像是建立二叉树进行二分查找。建立B-Tree结构，B+Tree结构、Hash结构
 

索引模块

主要用的是 B+ Tree数据结构 树

 

 

 

 

二叉查找树的弊端

再添加元素 它很容易转变为线性数据结构

 

B Tree树

这个树 我感觉有点像 2-3数

 

它的定义

ceil取得最大上限，比如3/2=1.5 但是这里要取2 往上取整

 

 

B+ Tree

B+树是B树的变体，其定义基本与B树相同，除了：

非叶子节点的子树指针与关键字个数相同

非叶子节点的子树指针P[i],指向关键字值[K[i]，K[i+1]]的子树

非叶子节点仅用来索引,数据都保存在叶子节点中

所有叶子节点均有一个链指向下一个叶子节点

B+ Tree更适合用来做存储索引

B+树的磁盘读写代价更低

B+树的查询效率更加稳定

B+树更有利于对数据库的扫描

 

Hash表也可以考虑一下

直接查找key 键值就好

Hash缺点

1.只满足=，IN 不能范围查询 只你能根据key来进行查找

2.不能利用部分索引键做查询

3.不能被用来避免数据的排序（因为hash索引中存放的是hash运算之后的值，hash值大小关系不一定和运算前的键值完全一样[不同key可能相同hash(key)]，数据库无法利用索引的数据来避免任何排序运算）

4.不能避免表扫描（[不同key可能相同hash(key)]）,也就是说索引可能对应多个记录，这些记录表需要进行扫描

5.遇到大量Hash值相等的情况后性能不一定比B-Tree索引高（极端情况所有key都对应同一个Hash（key）变成线性的了）

 

 

BitMap

支持位图索引的数据库比较少

知名的就有oracle