DBMS设计之初便假定数据主要位于非易失性的磁盘上，毕竟内存容量有限。而磁盘的访问速度远远大于内存访问速度，因此数据库存储引擎一项重要工作便是：管理数据在内存与非易失性存储之间移动，提高数据访问速度和效率。

1.数据的组织方式

数据在磁盘上以文件形式存储，数据库的存储引擎通常以固定大小的page(有的数据库称为block)为单位组织文件，读写磁盘均以page为单位。page里可以存放tuples货metadata货indexes等。每个page都有一个唯一标识，DBMS会维护page id到物理地址的映射关系。不同数据库DBMS产品page大小不同，比如：SQLite 1KB, Oracle/DB2 4KB, SQL Server/PG 8KB, MySQL 16KB。

不同的DBMS组织page的方式也不同，目前较常见的方式是Heap File Organization，page以链表(下图左)或page目录(下图右)的形式组织。

链表的方式可以通过记录header page，维护data page list和free page list。目录的方式(树)则维护特殊索引页，记录数据页位置。当然这两种方式是可以混合用，综合他们各自的优势，例如MySQL的默认存储引擎InnoDB B+树索引的实现。

目前还有另一种流行的组织方式Log Structued File Organization。这种方式存储log记录，而非传统意义上的tuple。当有insert/update/delete操作发生时，相应的记录会追加到数据库中。其中insert存储tuple，delete标记要删除的tuple，update只包含被更改的那部分信息。当需要去查询某个记录时，会根据对同一条记录的操作“组装”出最终结果，当然这里有很多优化策略和手段(建索引、compact等)，LevelDB，Hbase，RocksDB都是以这种形式存储组织数据的。

2.DBMS如何在内存和磁盘之间移动数据

数据以page为单位读入内存、写入磁盘，那么数据的移动何时发生，如何操作呢？OS的mmap功能可以将文件映射到内存，那么能不能直接利用OS的换页机制来处理page移动呢？这么做的问题在于(1)0DBMS丧失了对page的控制权，无法合理调度读取/刷盘。(2)OS在处理一个不在内存的OS page时会stall线程。当然一些数据库有办法在一定程度上规避部分问题，如早期的MongoDB。但完善的数据库系统一般会选择自己处理数据的移动、管理内存中的page。

数据库在内存的buffer pool便是用来缓存磁盘中读取上来的page。buffer pool 同样以page大小管理组织内存块，这样一块内存被称为frame。当DBMS需要时，会将磁盘中的page拷贝到一个frame中。当然有一个page table会记录内存中的所有page及相关的元信息(Dirty Flag、PIN counter等)。不少数据库不只有一个buffer pool。

那么哪些page会被载入内存呢？当查询的目标数据所在page不在内存时，会去磁盘读取，并放入buffer pool缓存，以备后用。这其中有很多优化策略。例如：(1)pre-fetch，即根据数据排列顺序或索引顺序预取后续page到内存，这对scan查询有很好的优化效果。(2)scan sharing，查询结果被多个相似的查询重用或某个表的cursor被多个查询复用。

而buffer pool满了后需要换页，一般选择LRU及其各类优化版本。