作为一个天天都在CRUD的程序员，你有没有想过，数据库是如何工作的？
我猜，你曾经无数次的翻开讲数据库的书籍和文章，但总是看着看着就被劝退，太多的专业术语把人头都搞大了。
image.png
等等，看这画风，今天是要卖课的节奏啊！
NO！绝不卖课，请放心阅读。
一直以来，我都很想深入学习一下数据库。我这个人学东西，如果只知其然而不知其所以然是非常难受的，啥都想去了解下背后的原理，学编程语言是这样，学操作系统也是这样。数据库这个东西天天都在用，所以学习一下背后的原理也是非常实用和有必要的。
但无论是哪本书、哪个视频教程，一打开就被无数的专业术语淹没，太多概念淹没了数据库最本质最核心的东西。
所以今天，让我们从一个最最最简单的模型开始，揭开数据库神秘的一角。
对我们使用者而言，数据库就像是一个黑盒子，你可以往它里面写入数据，也可以从它里面读出数据。
image.png
让我们暂时抛却SQL、网络连接、数据库等等概念，就来看这个最基本的需求：如果我们来实现一个可以对外提供读写数据的黑盒子，该怎么做？
假设我们的黑盒子很简单，里面只有一张表：user_info，用来存储用户信息。
表里面也很简单，只有三个字段，分别记录用户的ID、姓名和手机号。
user_id(uint32)
name(char[8])
phone(char[20])
我们可以用一个简单的结构体（或者一个class）来表示一条数据：
struct DataRecord{
uint32 user_id;
char name[8];
char phone[20];
};
user_id是一个uint32类型，占4个字节，name占8个字节，phone占20个字节，加起来一条数据总共占32个字节。
我们选择用一个文件来存储这些数据，存储非常简单，只需要一条一条的码在一起就行了，就像这样：
image.png
数据存储方式有了，接下来就是如何来读写了，我们来提供两个函数，分别来插入（insert）和查询（select）数据：
// 伪代码
void insert(Table* table, DataRecord record) {
fp = open(table->file_name);
fseek(fp, FILE_END);
write(fp, sizeof(DataRecord));
close(fp);
}
插入很简单，直接打开表对应的数据文件，然后把文件指针移动到文件尾部，接着追加数据，最后关闭文件，大功告成。这和把大象关进冰箱的步骤是一样一样的。
接下来是查询，我们提供一个可以通过id来查询用户的函数：
// 伪代码
DataRecord select(uint32 user_id) {
DataRecord result;
fp = open(table->file_name);
while (1) {
if (feof(fp))
break;
DataRecord record;
read(fp, &record, sizeof(DataRecord));
if (record.user_id == user_id) {
result = record;
break;
}
}
close(fp);
return result;
}
查询也很简单，我们打开文件，一条一条读取数据，然后比较用户id和给定的参数是否相同，直到找到符合条件的数据返回。
好了，以上，我们就实现了一个最最最基础的黑盒子：它里面有一张表，然后可以往里面写数据，从里面查数据。
现在来思考一下：
如果我们写了很多数据进去，比如几十万条，我们要查一个指定id的数据，要按照这样一条条比对，那不得等到猴年马月去了？
为什么要一条条比对呢？是因为我们的数据全都是一条一条码在一起的，完全没有顺序，所以要查询，只能这样一条条检查——全表扫描。
如果我们的数据是有顺序的呢？
假如我们插入数据的时候，是按照id从小到大排列着，这样我们就能用二分法快速找到指定id的数据了。
image.png
看上面这张图，假设我们要查找id为9的数据，我们可以读取第一条数据的id是1，就知道id为9的数据肯定在它后面。然后再读取最后一条数据id是12，就知道id为9的数据肯定在它前面，然后选择中间的数据读取，如此二分查找，很快就能锁定目标，不用每条数据都读取了。
因为每条数据都是32个字节，所以可以非常方便定位任意一条数据的位置：第n条数据的位置在32*(n-1)偏移处。
通过改变数据的存储组织形式，我们可以把数据查找的时间复杂度从O(N)下降到O(LogN)。
但如此一来，查找是变快了，但插入就麻烦了。以前的时候，我们直接把数据塞到文件最后就拍拍屁股走人了。但现在不行了，我们得把数据按照顺序，插入到合适的位置。
最麻烦的是，我们的数据是一条一条挨个码在一起的，如果中间某个位置要插入数据，就得把那个位置及其以后的数据通通往后移动，这就涉及到大量的数据复制移动，开销非常大。
要是每来一条insert操作就数据大量迁徙，那不得累得半死？
（其实不止插入，删除数据delete也同样如此麻烦）
就没有一种办法，可以同时插入快，查询也快吗？
仔细思考一下，前面我们把数据按顺序一条一条码在一起，查起来为什么快？
是因为做了排序以后，数据的存储位置有一条隐含的信息：如果id比我们要找的小，那我们要找的肯定在它后面；反之，如果id比我们要找的大，那我们要找的肯定在它前面。
之所以有这个规律，是因为我们按id的大小进行了排序存储。
那如果现在回到最开始的那种方式，不排序了，还是一条一条顺序来写入，就没有这个信息了。
但如果，我们在每条数据记录中增加一些额外的信息，用来指示id比它小的在哪里，id比它大的又在哪里，是不是就能顺着这些额外的信息“顺藤摸瓜”找到你要找的数据呢？
或许，聪明的你已经看出来了，这是按照“二叉树”的形式在记录数据位置信息。
image.png
但实际上，二叉树也才两个分叉，如果数据量很大的话，这棵树就会很高很瘦。
而每一次走入一个分支，就对应着一次文件I/O，所以在实际使用中，不会使用二叉树，而是使用开了非常多个叉的树——B树或者B+树。
image.png
如果用B树或者B+树来将文件中的数据在逻辑上组织起来，要查找数据就会快得多。
用id来查找数据问题解决了，但如果要用name来查找又该怎么办呢？
想一想，如果另外有一个文件，记录了每个name和这个name对应的数据记录在文件中的偏移位置，就像这样：
user_id数据位置(偏移)xuanyuan0shuaidi31april63dibingfa95
有了这个东西，是不是就简单很多了？只需要在这里搜一遍，拿到数据的位置，然后打开文件，定位到对应的偏移，一下就读出来了。
我们可以另外准备一个文件，同样使用B树或者B+树的形式来组织上面表格中的对应关系。
聪明的你可能已经看出来了，这玩意儿其实就是索引。当然实际中的数据库系统的索引实现或多或少有一些差别，但道理是通用的。
网友评论