简介：一套基于C++的MiniSQL数据库管理系统完整源码，参考CMU15445的BusTub框架并进行修改扩展，兼容原MiniSQL实验指导要求，面向数据库原理课程设计、实验或自学数据库内核的开发者。系统实现了缓冲池管理、B+树索引、记录管理等核心模块，支持持久化数据页分配回收状态，并扩展了Parser层语法树与执行引擎，可完成基本SQL语句的解析、执行及数据持久化，清晰呈现关系型数据库从命令到存储的完整链路。资源共377个文件，压缩包仅1.05MB，以C++头文件（h）和源文件（cc/cpp）为主体，配合Python辅助脚本、构建配置与单元测试代码，目录结构按模块划分清晰，便于阅读和二次开发。目前已有78人学习，对于想从零掌握数据库内核实现、准备相关项目答辩或技术面试的读者，这套源码不仅提供可运行的完整参考，还可作为进一步扩展索引优化、并发控制等机制的实验基础，性价比极高。 先泼一盆冷水：如果你想通过写完这个项目就成为“数据库内核专家”，那不太现实。但如果你想搞明白一条SQL从敲进终端、到解析、到查索引、到返回结果这中间到底发生了什么，那么MiniSQL是目前我能找到的、性价比最高的入门源码之一。它没有MySQL那么庞大到让人绝望的代码量，也没有SQLite那种为了嵌入式场景做了大量极致优化的复杂度，它就是一个刚刚好能跑起来、刚刚好能让你看懂的教学型关系型数据库管理系统。
我这次拿到的是“.zip源码包”形式，解压之后整个工程结构非常清晰，是基于C++从头实现的一个迷你关系型数据库，支持标准的SQL子集（CREATE TABLE、INSERT、DELETE、SELECT、DROP TABLE等），内置了B+树索引和基本的记录管理机制。对正在学C++、或者正在准备数据库课程设计的人来说，这是一份可以直接复现、二次开发的好素材。
1. 为什么是MiniSQL，而不是直接上手MySQL
很多人一听到“数据库管理系统”几个字，第一反应是“我直接去看MySQL源码不就行了？”。这个思路我不能说错，但MySQL那几百万行代码，对于只想理解核心原理的人来说，基本等于把一个刚学会游泳的人扔进太平洋。你会在各种锁机制、MVCC、binlog、优化器代价模型里彻底迷失。
MiniSQL的定位恰恰是填这个空档。它的目标不是“快”，不是“并发高”，而是“让原理可见”。整个系统的核心模块就那么几个：SQL解析、记录管理、索引管理、目录（元数据）管理、以及物理层的文件读写。任何一个有C++基础的人，花两三天时间通读一遍代码，再花几天时间亲手改几个功能，他对数据库的理解深度会远超那些背了一堆八股文的人。
另一个容易被忽略的点是，MiniSQL很适合作为面试项目的谈资。很多人简历上写着“熟悉MySQL索引原理”，但是被问到“B+树分裂的时候父节点怎么处理”就卡壳。如果你亲手写过MiniSQL的索引模块，这种问题根本不用背，因为那个坑你大概率踩过。
从工程结构上讲，MiniSQL也足够干净。它不像很多课程设计那样把所有代码塞进一个main.cpp里，而是按职责拆分了多个文件，每个类做的事情很单一。这种结构对于学习C++的抽象和封装也非常有帮助。
2. MiniSQL的整体架构拆解：四个核心模块如何协同
拿到源码之后，不要急着去读代码，先把骨架搭出来。MiniSQL大体上可以分成四个模块，搞清楚了它们的分工，你再去看代码就是带着地图逛迷宫，而不是瞎转。
2.1 解释器（Interpreter）模块
这个模块是用户与数据库交互的入口。它负责接收你输入的SQL字符串，做词法分析和语法分析，把它拆成内部能理解的操作指令。
具体来说，解释器会先把SQL语句切割成一个个token——比如SELECT * FROM student WHERE age > 20会被切成SELECT、*、FROM、student、WHERE、age、>、20——然后把这些token组装成一颗语法树或者一组内部调用。MiniSQL的这部分实现得比较朴素，没有用yacc/lex这类生成器，而是手写的递归下降解析（recursive descent parser），这对学习编译器原理其实更有帮助，因为你能看到每一步的匹配逻辑，而不是面对一个由工具生成的黑盒。
2.2 记录管理（Record Manager）模块
记录管理负责数据的实际存储和读取。表里的每一行数据，在这个模块里就是一个record。它需要考虑的是：这条记录放在文件的哪个页（page）？页满了怎么办？删除了记录之后空间怎么回收？
MiniSQL在记录层面用了一种相对简单的定长记录存储方式，每条记录有固定的大小，这样寻址和遍历都非常直接。和它相对的是一种叫变长记录的存储方式，处理起来要麻烦得多，但MiniSQL选择定长是为了降低理解门槛，我觉得这个取舍非常明智——你先搞懂定长怎么做，变长其实是在这个基础上加偏移管理而已。
这一层还需要维护一个记录ID（RID，Record ID），它像一个门牌号，告诉系统某条记录在哪个页的哪个槽位。这个门牌号后面会被索引模块引用，这是理解“索引指向数据”的关键桥梁。
2.3 索引管理（Index Manager）模块
这是MiniSQL的精华所在，也是整个项目里最值得反复研究的模块。它实现的是B+树索引，而且是基于磁盘的B+树，不是那种一次性加载到内存里的玩具实现。
索引模块的作用是什么？打个比方，没有索引的表就像一本没有目录的书，你想找某一页只能从头翻到尾。有了索引，你通过目录直接跳转到目标位置。MiniSQL的索引模块承担的就是“目录”的功能：给定一个键值（比如学号），它能快速找到对应记录的RID，然后通过RID去记录管理模块把数据取出来。
B+树之所以被选作数据库索引的默认结构，有两个核心原因：第一，它是矮胖的树，树的高度低，意味着磁盘IO次数少；第二，它的叶子节点用链表串联，非常适合范围查询。MiniSQL代码里对B+树的插入、删除、分裂、合并都做了完整实现，我建议你在看这部分时不要跳过任何一个函数。
2.4 目录管理（Catalog Manager）模块
目录管理管的是“元数据”——也就是关于数据的数据。比如你创建了一张student表，这张表叫什么名字、有哪些字段、每个字段是什么类型、有没有索引，这些信息都存在目录管理模块里。
MiniSQL的目录管理做得比较轻量，通常是维护几个内部表，把表信息和字段信息持久化到磁盘上。当你执行SELECT语句时，解释器会先问目录管理：“这张表存在吗？它有哪些列？”拿到这些信息之后才能去记录管理模块定位真实数据。
3. B+树索引模块：MiniSQL最容易翻车的地方
如果你让我只推荐一个文件精读，那一定是B+树的实现文件。我见过太多人栽在这里，包括我自己第一次写的时候。B+树看着原理简单，不就是多叉树嘛，但细节真是魔鬼。这里我重点说三个最容易被忽略的节点细节。
3.1 节点分裂的父子关系维护
当你往一个已经满了的叶子节点插入数据时，B+树需要把这一页数据从中间切开，分成两个节点，然后把中间的键上升到父节点。最容易被忽略的是：上升的键在左节点还是右节点？如果是数据重复，应该往哪边插？MiniSQL源码里对等值键的处理方式，建议你仔细看——它做的是允许重复键插入，那么查找时到底是返回第一条还是最后一条，这直接影响了WHERE条件的正确性。
另一个经典坑是：根节点分裂时，树的高度会增加一层。这时候需要新建一个根节点，把原来的根节点降级为子节点。很多人写到这里就忘了更新文件头里记录的高度信息，结果插入几次数据之后整个索引读取都是错的。
3.2 节点分裂的时机判断
B+树的节点分裂不是元素数量一超过阈值就立刻分裂的。标准的做法是：先插入，如果插入后节点满了，再分裂。但“满了”这个判断的边界值特别容易出bug。比如一个节点的容量是4个键，你插入第5个键时它才分裂，还是插入第4个时就分裂？MiniSQL的实现里用了一个很直观的判断方式：尝试插入，如果插入位置越界则触发分裂。读代码时你只要盯着那个if (curSize >= maxSize)类似的判断，就能理解这个模块的边界处理逻辑。
3.3 叶子节点与非叶子节点的不同“链接”策略
B+树的叶子节点需要用兄弟指针串成一个链表，这样像SELECT * FROM student WHERE age BETWEEN 18 AND 22这种范围查询，就能在找到起点后顺着链表往后扫，而不需要每次都从根节点重新遍历。但非叶子节点是没有这个链表的。
这个设计导致了一个现象：同一个键，可能既存在于非叶子节点（作为路由信息），也存在于叶子节点（作为真实数据）。如果你在删除时只删了叶子节点的记录，忘了更新非叶子节点的路由键，树就会错乱。MiniSQL对删除的处理是“当节点太稀疏时尝试从兄弟节点借或者合并”，怎么保证借完之后父节点的路由键还是有序的，这段逻辑非常值得反复品味。
3.4 序列化与持久化：内存里的树如何落到磁盘
这个点特别容易翻车，因为它和纯内存的数据结构不一样。内存里的B+树可以用指针互相连接，但磁盘上的B+树节点是用页号（page number）来互相引用的。所以每个节点里存的“孩子指针”其实是一个整数页号，而不是一个C++指针。
十几年前我在别的地方写B+树就是直接把struct node*往文件里写，写完读出来直接崩——原因就是进程的虚拟地址在下次运行时完全变了，你存的指针全成了野指针。MiniSQL的做法是在节点内部维护每个子节点的页号，在需要访问内存时先把这个节点整体加载（或者用LRU做页缓存），用页号去文件里定位。这个设计和磁盘IO紧密结合，是真正的“数据库思维”。代码里会涉及重新节点开页、释放旧页等逻辑，看的时候请拿一张草稿纸，画出磁盘上的页分布图，不然很容易绕晕。
4. 从一条SQL到结果返回：核心流程走读
我现在带你把一条最简单的SQL在MiniSQL里的完整旅程走一遍。假设我们已经建好了一张学生表，现在执行这条语句：
SELECT * FROM student WHERE student_id = 2024001;4.1 第一步：语法解析
解释器接收到这条字符串，先做词法分析，把SELECT、*、FROM、student、WHERE、student_id、=、2024001这些token识别出来。接着语法分析会判断这是一条查询语句，并且把查询条件student_id = 2024001解析成一个表达式对象。
MiniSQL的表达式处理不算复杂，它把student_id解析为列名，2024001解析为字面量，=解析为比较操作符，然后形成一个类似(列名 操作符 值)的三元组结构。这个结构后面会被用来生成查询计划——虽然MiniSQL没有真正意义上的优化器，但你可以理解为“有条件就用索引，没条件就全表扫描”这样一条简单的决策逻辑。
如果你也想自己手写解析器，我建议先画一个逻辑结构体，不要一上来就写递归，不然改着改着很容易把自己绕进去。具体来说，可以先把所有Token类型枚举出来，然后把SQL的语法规则用EBNF或简单的语法图表示出来，再照着图写代码，这样出错时更好排查。
4.2 第二步：元数据查表
解释器发现要查询student表，于是去目录管理模块查这张表的定义。目录管理返回的信息包括：这张表有哪些字段（字段名、类型、长度）、主键是什么、有没有已定义的索引。
我见过很多初学者在这一步犯迷糊：为什么查数据之前要先查“表的信息”？打个比方，你要去图书馆找一本书，你得先知道这本书在哪个书架、分类编号是什么。目录管理就是那个查询系统。没有它，记录管理层拿到一堆二进制字节也不知道该怎么解释成结构体。
4.3 第三步：索引查找还是全表扫描
现在系统需要拿到student_id = 2024001这条记录。如果student_id上有索引（这是MiniSQL的标准功能之一），索引模块会以2024001为键，在B+树里查找对应的RID。
这个查找的过程是：从根节点开始，比较键值决定走哪个子节点，层层下探，直到叶子节点，然后在叶子节点的键数组里二分查找，找到目标键，取出它对应的RID。整个过程的复杂度是对数级的，这就是索引的价值所在。
如果没有索引，MiniSQL会退化成全表扫描——从表文件的第一个页开始，逐条读取记录，判断student_id是否等于2024001。这个对比非常直观地告诉你，为什么数据库里不能随便缺索引。
4.4 第四步：记录获取与结果输出
拿到RID之后，记录管理模块根据这个门牌号，去数据文件的对应页、对应槽位，把一条完整的record读出来并解析成列值。最后MiniSQL把这些值格式化输出到终端，就完成了整个查询。
走完这一条路，你再回头看数据库课本里的“SQL执行流程”，会觉得所有概念都有落点。这比单纯背知识点有用太多了。
5. 让MiniSQL真正“能跑”：环境配置、编译与常见报错
MiniSQL源码包通常是没有依赖第三方库的，这对环境配置来说是件好事。你只需要一个支持C++11以上的编译器，基本上就能顺利编译。我用过的环境有Windows上的Visual Studio，也有Linux下的g++，都能跑通。不过有几个坑我必须提前说。
5.1 编译器标准要够新
很多MiniSQL源码会用到std::unique_ptr、std::unordered_map、以及一些C++11才有的语法特性。如果你用的是比较老的GCC版本，或者Visual Studio里没有启用C++11标准，编译时会报一堆“xxx does not name a type”之类的错误。
解决办法很简单：在编译选项里指定标准。g++的话加-std=c++11，如果代码里用了更新的特性，比如std::optional或者结构化绑定，那就需要-std=c++17。先看一眼源码里有没有用到这些新特性，再决定用哪个标准，不要无脑拉满。
5.2 文件路径与工作目录问题
MiniSQL在运行时会创建数据文件，比如student.tbl、student.idx，这些文件的读写路径通常基于当前工作目录。如果你从IDE里直接Run但工作目录不对，程序可能启动了但找不到已有的数据库文件，甚至直接创建一套新的空库，让你误以为数据丢了。
遇到这种情况，先检查程序的工作目录，确保它和你上次运行时一致。最简单的办法是用命令行切到源码目录再运行可执行文件，而不是从IDE的默认目录跑。
5.3 常见崩溃排查思路
如果你在运行过程中遇到Segmentation Fault或者Windows下的崩溃弹窗，不用慌。先看崩溃时的调用栈，MiniSQL的模块划分很清晰，栈顶大概率能直接告诉你是在索引模块还是记录模块挂的。
一种很常见的情况是：你在建表之后插入了一些数据，然后重启程序，旧数据不在了或者读取报错。这通常是因为记录文件或者索引文件的持久化逻辑在某些边界条件下没有正确落盘，或者文件头信息没有更新。我的建议是加日志输出，在关键节点打印当前页号和键值，跑一个最小复现用例，很快就会定位出问题。
6. 从课程作业到简历项目：MiniSQL还可以怎么进化
等你把MiniSQL跑通，并且能流畅地把它内部原理讲清楚之后，下一步就是考虑怎么让它从“课程作业”变成“简历项目”。原版MiniSQL的功能可以说是“五脏俱全但样样精简”，这恰恰给了你自由发挥的空间。我列出几个值得投入的方向，按难度从低到高。
6.1 加入JOIN操作
原版MiniSQL通常只支持单表查询。如果能实现一个简单的嵌套循环连接（Nested Loop Join），支持SELECT * FROM student, course WHERE student.id = course.sid这种双表查询，那么整个系统的实用性和你的代码理解深度都会上一个台阶。
这个功能涉及语法树扩展、多表扫描、以及记录拼接，是不错的挑战。关键在于理解两个表的数据如何按条件匹配，以及如何在“驱动表”和“被驱动表”之间切换循环顺序来减少扫描次数。
6.2 加入事务与WAL日志（简化版）
数据库事务的ACID特性是面试的高频话题。你不需要实现完整的MVCC，只要实现简单的BEGIN/COMMIT/ROLLBACK语义，配合一个简化版的Write-Ahead Log（预写日志），就能在系统崩溃后恢复未提交的事务，这会让你的项目深度立刻不一样。
WAL的核心思想是：在修改磁盘上的数据页之前，先把修改操作写进一个日志文件，保证日志先落盘、数据后落盘。崩溃时通过日志内容重放操作，就能回到一致状态。对于MiniSQL这种单线程的教学库，这个实现并不算难，但对事务的理解非常到位。
6.3 支持更多SQL语法
比如UPDATE、LIKE模糊匹配、ORDER BY排序、COUNT/SUM聚合函数，这些都是比较自然的扩展点。每加一个语法特性，你就得在解释器、执行器多个模块里同步改动，这个过程会让你对“SQL是如何一步步变成机器操作”这件事的理解越来越立体。
我个人的建议是：不要一次性铺开做所有扩展，一次只挑一个，做完跑通、写测试、写文档，再进入下一个。这样每完成一项，你都能讲清楚“我做了什么、为什么这么做、遇到了什么问题、怎么解决的”——这套讲法在技术面试里相当加分。
最后再说一句关于代码阅读顺序的话。如果你刚解压这个MiniSQL源码包，我建议的阅读顺序是：先读目录管理模块（最简单，能帮你理解表和字段的数据结构），再读记录管理模块（理解数据怎么存），然后啃索引模块（这是硬骨头但值得），最后再看解释器模块（你会发现前面几个模块在这里被串起来了）。按照这个顺序，你会有一种“拼图一块块合拢”的爽感。别看反了，一上来就死磕解释器会让你困在一堆token和递归调用里出不来。
本文还有配套的精品资源，点击获取
)