理解数据库（一）：数据组织方式与索引

我们常说的“数据库”，比如“MySQL”、“Oracle”等，其实严格来说是DBMS(Database Management System)，数据库只是一个存储数据着数据的仓库，而DBMS做的事是让我们能够操作数据库，比如解析SQL、DML等，都是DBMS在支持着。 在DBMS之下，又有着存储引擎，为DBMS提供数据增删改查的支持，不同的存储引擎提供不同的特性，负责组织数据的就是存储引擎。

一、数据的组织方式

1. 单条记录的结构

每一个字段都需要定义一个数据类型(DataType)，数据类型在数据组织时的意义是确定数据长度，存储介质将会为其分配合适长度的空间。 每个字段被按照顺序组织起来，并且在开头存储着这一行的某些头信息(MetaData)，例如记录总长度、时间戳等，这就组成了一条在硬盘上被存储的完整记录：

如果是变长记录，比如某一个字段是varchar(256)，则会在头信息后紧接着存储这一列的指针，指向这个字段的值存储地址（一般是在记录的末尾）：

由于每次从磁盘中读取数据的单位是页(Page)，为了保证读取速度，一般数据库都会要求一条记录的长度不超过一页（页的长度不固定，可以被设置，一般是4kb），保证一次读取就能读到一条完整记录，而不需要跨页读取，因此对于某些存储着大数据的字段，比如图片、视频，他们往往被独立存储到其他文件，而不与记录中的其他小字段存储在一起。

2. 多条记录如何被组织

行是一条具有完整意义的记录，被按照一定的规则，依次存储在文件中。 记录在文件中有以下几种主要的组织方法：

1. 堆文件

记录与记录之间没有顺序关系，每条记录可以存放在文件中的任何地方，只要想被存储的地址有足够空间。

2. 顺序文件

也就是遵循某个搜索码(Search key)的顺序，依次存储每一条记录。搜索码是一系列搜索条件的组合，可以是一个键，也可以是多个键组合。如下图，按照第二列，也就是姓名的顺序去决定记录的存储顺序：

这种方式非常利于顺序读取，因为连续的记录都保存在连续的页中，可一次性读出多个页获得批量的记录，而无需多次寻址多次读取。 但是这种方式不利于记录的删除和插入，因为删除记录时需要将后面的记录依次前移，插入记录时需要将后面的记录依次后移，如果受影响的记录多，效率将会很低。 为了解决每次插入删除数据都需要移动后面的记录的问题，现实中可能采取了指针，也就是每一条记录中保存着指向下一条记录的指针，当有记录被删除时，仅仅修改指针，避免记录的移动；当有记录插入时，先检查在合适的位置是否有空闲空间，如果没有，采用开辟 溢出块的方式，不直接插入至合适位置，而是在其他空间存储这条记录，然后修改上一条记录的指针指向这条新插入的记录，去避免大量记录的移动：

但是如果大量的记录都存储在溢出块中，顺序文件本身所带来的好处就大打折扣，因为很多记录已经不再在物理上按顺序存储，那么顺序获取记录时，就可能需要多次寻址多次读取，而不能通过一次性读取连续的页来获取连续的记录。此时，文件就需要被 重组，会将所有记录重新组织成完全物理邻接的文件。

3. 聚簇文件

前面提到的顺序文件是不同的表存储在不同的文件中，但是某些具体应用场景下，可能常常涉及多表查询，比如有一个名为Singers的表保存着歌手信息，又有一个名为Albums的表保存着每个歌手发布的专辑信息，如果你正在开发一个音乐播放器，那么涉及的场景一般都是需要找出某个歌手发布的所有专辑展示给客户，如果不同的表保存在不同的文件中，那么需要进行连接(Join) ，复杂度比较高，但是如果将每个歌手的专辑信息都在物理上存储在歌手信息之后，也就是两张表混合存放在同一个文件中:

采用聚簇文件则不需要进行Join操作，找到Singer后，直接顺序读取后面的页，就能拿到指定歌手的所有专辑，提高了查询效率。

4. 散列文件

散列文件完全没有顺序，每条记录应该存放的位置，是根据搜索码的Hash值决定的，因此插入删除都不涉及记录移动，且由于搜索码的Hash值直接决定了存储位置，所以查找符合特定搜索码的记录非常快，但是不支持范围查找与顺序读取。

3. 记录的读取

DBMS维护着自己的缓存空间，使用一些缓存置换算法尽量确保那些经常