如果有人问你数据库的原理，看这篇文章。（超长预警）

长文，相当的通透。以下为scrat进行总结后的删减版。

下面假定你已经知道时间复杂度

关系型数据库无处不在，而且种类繁多，从小巧实用的 SQLite 到强大的 Teradata 。但很少有文章讲解数据库是如何工作的。

 

作为一个开发人员，我不喜欢用我不明白的东西。数据库已经使用了40年之久，一定有理由的。关系型数据库非常有趣，因为它们是基于实用而且可复用的概念。如果你对了解一个数据库感兴趣，但是从未有时间或意愿来刻苦钻研这个内容广泛的课题，你应该喜欢这篇文章。

虽然本文标题很明确，但我的目的并不是讲如何使用数据库。因此，你应该已经掌握怎么写一个简单的 join query（联接查询）和CRUD操作（创建读取更新删除），否则你可能无法理解本文。这是唯一需要你了解的，其他的由我来讲解。

由于这是个很大的话题，我将集中探讨我认为必要的内容：数据库处理SQL查询的方式。我仅仅介绍数据库背后的基本概念，以便在读完本文后你会对底层到底发生了什么有个很好的了解。

由于本文是个长篇技术文章，涉及到很多算法和数据结构知识，你尽可以慢慢读。有些概念比较难懂，你可以跳过，不影响理解整体内容。

这篇文章大约分为3个部分：

• 底层和上层数据库组件概况
• 查询优化过程概况
• 事务和缓冲池管理概况

 

回到基础

很久很久以前（在一个遥远而又遥远的星系……)，开发者必须确切地知道他们的代码需要多少次运算。他们把算法和数据结构牢记于心，因为他们的计算机运行缓慢，无法承受对CPU和内存的浪费。

在这一部分，我将提醒大家一些这类的概念，因为它们对理解数据库至关重要。我还会介绍数据库索引的概念。

O(1) vs O(n^2)

现今很多开发者不关心时间复杂度……他们是对的。

但是当你应对大量的数据（我说的可不只是成千上万哈）或者你要争取毫秒级操作，那么理解这个概念就很关键了。而且你猜怎么着，数据库要同时处理这两种情景！我不会占用你太长时间，只要你能明白这一点就够了。这个概念在下文会帮助我们理解什么是基于成本的优化。

概念：时间复杂度用来检验某个算法处理一定量的数据要花多长时间。为了描述这个复杂度，计算机科学家使用数学上的『简明解释算法中的大O符号』。这个表示法用一个函数来描述算法处理给定的数据需要多少次运算。

数据量低时，O(1) 和 O(n^2)的区别可以忽略不计。比如，你有个算法要处理2000条元素。

• O(1) 算法会消耗 1 次运算
• O(log(n)) 算法会消耗 7 次运算
• O(n) 算法会消耗 2000 次运算
• O(n*log(n)) 算法会消耗 14,000 次运算
• O(n^2) 算法会消耗 4,000,000 次运算

O(1) 和 O(n^2) 的区别似乎很大（4百万）,但你最多损失 2 毫秒，只是一眨眼的功夫。确实，当今处理器每秒可处理上亿次的运算。这就是为什么性能和优化在很多IT项目中不是问题。

我说过，面临海量数据的时候，了解这个概念依然很重要。如果这一次算法需要处理 1,000,000 条元素（这对数据库来说也不算大）。

• O(1) 算法会消耗 1 次运算
• O(log(n)) 算法会消耗 14 次运算
• O(n) 算法会消耗 1,000,000 次运算
• O(n*log(n)) 算法会消耗 14,000,000 次运算
• O(n^2) 算法会消耗 1,000,000,000,000 次运算

我没有具体算过，但我要说，用O(n^2) 算法的话你有时间喝杯咖啡（甚至再续一杯！）。如果在数据量后面加个0，那你就可以去睡大觉了。

继续深入

为了让你能明白

• 搜索一个好的哈希表会得到 O(1) 复杂度
• 搜索一个均衡的树会得到 O(log(n)) 复杂度
• 搜索一个阵列会得到 O(n) 复杂度
• 最好的排序算法具有 O(n*log(n)) 复杂度
• 糟糕的排序算法具有 O(n^2) 复杂度

注：在接下来的部分，我们将会研究这些算法和数据结构。

有多种类型的时间复杂度

• 一般情况场景
• 最佳情况场景
• 最差情况场景

时间复杂度经常处于最差情况场景。

这里我只探讨时间复杂度，但复杂度还包括：

• 算法的内存消耗
• 算法的磁盘 I/O 消耗

当然还有比 n^2 更糟糕的复杂度，比如：

• n^4：差劲！我将要提到的一些算法具备这种复杂度。
• 3^n：更差劲！本文中间部分研究的一些算法中有一个具备这种复杂度（而且在很多数据库中还真的使用了）。
• 阶乘 n：你永远得不到结果，即便在少量数据的情况下。
• n^n：如果你发展到这种复杂度了，那你应该问问自己IT是不是你的菜。

注：我并没有给出『大O表示法』的真正定义，只是利用这个概念。可以看看维基百科上的这篇文章。

 

归并排序

当你要对一个集合排序时你怎么做？什么？调用 sort() 函数……好吧，算你对了……但是对于数据库，你需要理解这个 sort() 函数的工作原理。

优秀的排序算法有好几个，我侧重于最重要的一种：归并排序。你现在可能还不了解数据排序有什么用，但看完查询优化部分后你就会知道了。再者，归并排序有助于我们以后理解数据库常见的联接操作，即归并联接 。

这个方法之所以有效，是因为两个4元素序列都已经排好序，你不需要再『回到』序列中查找比较。

合并排序是把问题拆分为小问题，通过解决小问题来解决最初的问题（注：这种算法叫分治法，即『分而治之、各个击破』）。如果你不懂，不用担心，我第一次接触时也不懂。如果能帮助你理解的话，我认为这个算法是个两步算法：

• 拆分阶段，将序列分为更小的序列
• 排序阶段，把小的序列合在一起（使用合并算法）来构成更大的序列

拆分阶段

 

在拆分阶段过程中，使用3个步骤将序列分为一元序列。步骤数量的值是 log(N) （因为 N=8, log(N)=3）。

排序阶段

 因为有 log(N) 个步骤，整体成本是 N*log(N) 次运算。

归并排序的强大之处，为什么这个算法如此强大？

因为：

• 你可以更改算法，以便于节省内存空间，方法是不创建新的序列而是直接修改输入序列。

注：这种算法叫『原地算法』(in-place algorithm)

• 你可以更改算法，以便于同时使用磁盘空间和少量内存而避免巨量磁盘 I/O。方法是只向内存中加载当前处理的部分。在仅仅100MB的内存缓冲区内排序一个几个GB的表时，这是个很重要的技巧。

注：这种算法叫『外部排序』(external sorting)。

• 你可以更改算法，以便于在 多处理器/多线程/多服务器 上运行。

比如，分布式归并排序是Hadoop（那个著名的大数据框架）的关键组件之一。

• 这个算法可以点石成金（事实如此！）

这个排序算法在大多数（如果不是全部的话）数据库中使用，但是它并不是唯一算法。如果你想多了解一些，你可以看看 这篇论文，探讨的是数据库中常用排序算法的优势和劣势。

 

阵列，树和哈希表

既然我们已经了解了时间复杂度和排序背后的理念，我必须要向你介绍3种数据结构了。它们是现代数据库的支柱。我还会介绍数据库索引的概念。

阵列

二维阵列是最简单的数据结构。一个表可以看作是个阵列，比如：

这个二维阵列是带有行与列的表：

• 每个行代表一个主体
• 列用来描述主体的特征
• 每个列保存某一种类型对数据（整数、字符串、日期……）

虽然用这个方法保存和视觉化数据很棒，但是当你要查找特定的值它就很糟糕了。 举个例子，如果你要找到所有在 UK 工作的人，你必须查看每一行以判断该行是否属于 UK 。这会造成 N 次运算的成本（N 等于行数），还不赖嘛，但是有没有更快的方法呢？这时候树就可以登场了（或开始起作用了）。

 

树和数据库索引

二叉查找树是带有特殊属性的二叉树，每个节点的关键字必须：

• 比保存在左子树的任何键值都要大
• 比保存在右子树的任何键值都要小

查询的成本就是树内部的层数。一共有 log(N)层。所以这个查询的成本是 log(N)。

回到我们的问题

上文说的很抽象，我们回来看看我们的问题。前表中代表某人的国家的字符串。假设你有个树包含表中的列『country』：

• 如果你想知道谁在 UK 工作
• 你在树中查找代表 UK 的节点
• 在『UK 节点』你会找到 UK 员工那些行的位置

这次搜索只需 log(N) 次运算，而如果你直接使用阵列则需要 N 次运算。你刚刚想象的就是一个数据库索引。

 

B+树索引

查找一个特定值这个树挺好用，但是当你需要查找两个值之间的多个元素时，就会有大麻烦了。你的成本将是 O(N)，因为你必须查找树的每一个节点，以判断它是否处于那 2 个值之间（例如，对树使用中序遍历）。而且这个操作不是磁盘I/O有利的，因为你必须读取整个树。我们需要找到高效的范围查询方法。为了解决这个问题，现代数据库使用了一种修订版的树，叫做B+树。在一个B+树里：

• 只有最底层的节点（叶子节点）才保存信息（相关表的行位置）
• 其它节点只是在搜索中用来指引到正确节点的。

B+ 树

 

问题是：如果你在数据库中增加或删除一行（从而在相关的 B+树索引里）：

• 你必须在B+树中的节点之间保持顺序，否则节点会变得一团糟，你无法从中找到想要的节点。
• 你必须尽可能降低B+树的层数，否则 O(log(N)) 复杂度会变成 O(N)。

换句话说，B+树需要自我整理和自我平衡。谢天谢地，我们有智能删除和插入。但是这样也带来了成本：在B+树中，插入和删除操作是 O(log(N)) 复杂度。所以有些人听到过使用太多索引不是个好主意这类说法。没错，你减慢了快速插入/更新/删除表中的一个行的操作，因为数据库需要以代价高昂的每索引 O(log(N)) 运算来更新表的索引。再者，增加索引意味着给事务管理器带来更多的工作负荷（在本文结尾我们会探讨这个管理器）。

想了解更多细节，你可以看看 Wikipedia 上这篇关于B+树的文章。如果你想要数据库中实现B+树的例子，看看MySQL核心开发人员写的这篇文章 和 这篇文章。两篇文章都致力于探讨 innoDB(MySQL引擎)如何处理索引。

 

哈希表

最后一个重要的数据结构是哈希表。当你想快速查找值时，哈希表是非常有用的。而且，理解哈希表会帮助我们接下来理解一个数据库常见的联接操作，叫做『哈希联接』。这个数据结构也被数据库用来保存一些内部的东西（比如锁表或者缓冲池，我们在下文会研究这两个概念）。

哈希表这种数据结构可以用关键字来快速找到一个元素。为了构建一个哈希表，你需要定义：

• 元素的关键字
• 关键字的哈希函数。关键字计算出来的哈希值给出了元素的位置（叫做哈希桶）。
• 关键字比较函数。一旦你找到正确的哈希桶，你必须用比较函数在桶内找到你要的元素。

我们来看一个形象化的例子：

这个哈希表有10个哈希桶（哈希函数）。因为我懒，我只给出5个桶，但是我知道你很聪明，所以我让你想象其它的5个桶。我用的哈希函数是关键字对10取模，也就是我只保留元素关键字的最后一位，用来查找它的哈希桶：

• 如果元素最后一位是 0，则进入哈希桶0，
• 如果元素最后一位是 1，则进入哈希桶1，
• 如果元素最后一位是 2，则进入哈希桶2，
• 我用的比较函数只是判断两个整数是否相等。

比方说你要找元素 78：

• 哈希表计算 78 的哈希码，等于 8（78 % 10 = 8）。
• 查找哈希桶 8，找到的第一个元素是 78。
• 返回元素 78。
• 查询仅耗费了 2 次运算（1次计算哈希值，另一次在哈希桶中查找元素）。

现在，比方说你要找元素 59：

• 哈希表计算 59 的哈希码，等于9。
• 查找哈希桶 9，第一个找到的元素是 99。因为 99 不等于 59， 那么 99 不是正确的元素。
• 用同样的逻辑，查找第二个元素(9)，第三个(79)，……，最后一个(29)。
• 元素不存在。
• 搜索耗费了 7 次运算。

你可以看到，根据你查找的值，成本并不相同。

如果我把哈希函数改为关键字对 1,000,000 取模（就是说取后6位数字），第二次搜索只消耗一次运算，因为哈希桶 00059 里面没有元素。真正的挑战是找到好的哈希函数，让哈希桶里包含非常少的元素。

在我的例子里，找到一个好的哈希函数很容易，但这是个简单的例子。当关键字是下列形式时，好的哈希函数就更难找了：

• 1 个字符串（比如一个人的姓）
• 2 个字符串（比如一个人的姓和名）
• 2 个字符串和一个日期（比如一个人的姓、名和出生年月日）
• …

如果有了好的哈希函数，在哈希表里搜索的时间复杂度是 O(1)。

 

阵列 vs 哈希表

为什么不用阵列呢 ？

嗯，你问得好。

• 一个哈希表可以只装载一半到内存，剩下的哈希桶可以留在硬盘上。
• 用阵列的话，你需要一个连续内存空间。如果你加载一个大表，很难分配足够的连续内存空间。
• 用哈希表的话，你可以选择你要的关键字（比如，一个人的国家和姓氏）。

想要更详细的信息，你可以阅读我在Java HashMap 上的文章，是关于高效哈希表实现的。你不需要了解Java就能理解文章里的概念。

 

 

全局概览

我们已经了解了数据库内部的基本组件，现在我们需要回来看看数据库的全貌了。

数据库是一个易于访问和修改的信息集合。不过简单的一堆文件也能达到这个效果。事实上，像SQLite这样最简单的数据库也只是一堆文件而已，但SQLite是精心设计的一堆文件，因为它允许你：

• 使用事务来确保数据的安全和一致性
• 快速处理百万条以上的数据

数据库一般可以用如下图形来理解：

撰写这部分之前，我读过很多书/论文，它们都以自己的方式描述数据库。总而言之：数据库是由多种互相交互的组件构成的。

核心组件：

• 进程管理器（process manager）：很多数据库具备一个需要妥善管理的进程/线程池。再者，为了实现纳秒级操作，一些现代数据库使用自己的线程而不是操作系统线程。
• 网络管理器（network manager）：网路I/O是个大问题，尤其是对于分布式数据库。所以一些数据库具备自己的网络管理器。
• 文件系统管理器（File system manager）：磁盘I/O是数据库的首要瓶颈。具备一个文件系统管理器来完美地处理OS文件系统甚至取代OS文件系统，是非常重要的。
• 内存管理器（memory manager）：为了避免磁盘I/O带来的性能损失，需要大量的内存。但是如果你要处理大容量内存你需要高效的内存管理器，尤其是你有很多查询同时使用内存的时候。
• 安全管理器（Security Manager）：用于对用户的验证和授权。
• 客户端管理器（Client manager）：用于管理客户端连接。
• ……

工具：

• 备份管理器（Backup manager）：用于保存和恢复数据。
• 复原管理器（Recovery manager）：用于崩溃后重启数据库到一个一致状态。
• 监控管理器（Monitor manager）：用于记录数据库活动信息和提供监控数据库的工具。
• Administration管理器（Administration manager）：用于保存元数据（比如表的名称和结构），提供管理数据库、模式、表空间的工具。【译者注：好吧，我真的不知道Administration manager该翻译成什么，有知道的麻烦告知&#x