从零实现数据库：深入理解B+Tree、WAL与MVCC核心机制

你是否曾好奇数据库这个支撑着几乎所有现代应用的“黑盒”内部究竟是如何运作的当你在命令行敲下SELECT * FROM users时背后发生了什么当你的应用每秒处理成千上万的事务数据库是如何保证数据不丢失、不出错的面对市面上成熟的 MySQL、PostgreSQL为什么还有人会想“从零开始写一个数据库”这并非一个象牙塔里的学术练习。理解数据库的内部构造是解决复杂性能瓶颈、进行深度系统调优、乃至设计全新数据架构的基石。当你遇到“数据库连接池耗尽”、“死锁频发”、“主从延迟巨大”或“某个查询莫名其妙变慢”时仅靠调整配置和索引往往治标不治本。真正的解药藏在 BTree、WAL预写式日志、MVCC多版本并发控制这些核心机制的理解之中。本文将通过一个实践项目——“从零开始编写一个简单的数据库”——来为你揭开这层神秘面纱。我们的目标不是造一个替代品而是亲手搭建一个具备基础功能的“玩具”数据库从而透彻理解数据存储、索引、事务和查询处理的核心原理。读完本文你将不仅能回答开头的那些问题更能获得一种“透视”现有数据库的能力在面对生产环境中的棘手数据问题时思路将变得前所未有的清晰。1. 为什么你需要理解“从零开始的数据库”在深入代码之前我们必须先回答一个根本问题在开源数据库如此成熟的今天为什么还要费时费力去理解甚至动手实现一个简易数据库第一为了建立系统性的认知地图。使用数据库和应用数据库是两回事。很多开发者熟悉 SQL 语法和 ORM 框架但对数据如何从磁盘加载到内存、索引如何加速查询、事务如何保证 ACID 特性只有模糊的概念。这种认知断层会导致优化时无处下手排查问题时只能盲目尝试。通过从零构建你将亲眼看到一条 SQL 语句是如何被解析、规划、执行最终转化为磁盘 IO 和内存操作的。这张完整的“认知地图”是进行高级架构设计和性能调优的前提。第二为了精准定位和解决深层次问题。网络热词中频繁出现的“database is corrupt”、“performance is a bottleneck”、“master database cannot be accessed”等错误其根源往往深植于存储引擎或并发控制机制。例如“working copy database is corrupt”可能与日志恢复机制有关“CPU or database performance is a bottleneck”可能与锁竞争或无效的 IO 有关。如果你了解 WAL 如何保证崩溃恢复了解 BTree 的页分裂如何影响写入性能你就能更快地定位到问题本质而不是停留在“重启服务”或“增加硬件”的层面。第三为了在技术选型与架构设计中做出明智决策。理解不同存储结构如 LSM-Tree vs. BTree的读写放大差异你就能在为 IoT 时序数据或金融交易系统选择数据库时更有底气。理解 MVCC 的实现方式你就能更好地评估数据库在高并发场景下的表现。这种底层知识让你从被动的“工具使用者”转变为主动的“方案设计者”。因此本文的旅程是一次从“用户视角”到“创造者视角”的升级。我们将聚焦于几个最核心的模块用代码将它们串联起来。2. 核心概念与我们的目标在开始动手前我们需要明确我们要构建的“数据库”的边界和核心概念。2.1 数据库系统的核心分层一个完整的数据库管理系统通常包含以下层次连接管理与协议层处理客户端连接解析通信协议如 MySQL 协议。SQL 解析与优化层将 SQL 字符串解析为抽象语法树进行查询优化生成执行计划。事务管理与并发控制层管理事务的开启、提交、回滚通过锁或 MVCC 机制处理并发冲突。存储引擎层负责数据的实际存储、索引、存取方法。这是最核心、最影响性能的部分。存储管理层与操作系统交互管理磁盘空间页、区、段处理文件 IO。我们的“玩具”数据库将重点关注存储引擎层和存储管理层并简化其他部分。我们会实现一个简单的键值存储这其实是许多复杂数据库如 MySQL 的 InnoDB的核心抽象。在这个基础上我们可以模拟出表、索引和事务的概念。2.2 关键机制解析BTree 索引为什么是数据库索引的默认选择因为它提供了高效的范围查询和顺序扫描能力所有数据都存储在叶子节点且树的高度稳定查询性能可预测。WAL (Write-Ahead Logging)如何保证崩溃后数据不丢失核心原则是在数据页被修改并刷回磁盘之前必须先将描述这次修改的日志记录持久化到磁盘。这样即使系统崩溃重启后也能通过“重放”日志来恢复数据到一致状态。MVCC (Multi-Version Concurrency Control)如何实现高并发读写它为每一行数据维护多个版本。读操作可以访问一个快照版本而写操作创建新版本从而让读写操作互不阻塞极大提升了并发度。我们的项目目标实现一个支持以下功能的单机键值存储引擎基本的PUT(key, value)和GET(key)操作。基于 BTree 的索引支持按 key 高效检索。简单的 WAL 机制保证进程崩溃后数据可恢复。简易的事务支持BEGIN, COMMIT, ROLLBACK基于锁实现。一个简单的 SQL 解析外壳能将INSERT和SELECT语句映射到我们的键值操作上。3. 环境准备与项目结构我们将使用Go 语言进行实现。Go 语言简洁的语法、强大的标准库和内置的并发原语非常适合用来清晰地表达数据结构和并发逻辑。当然核心思想是语言无关的。环境要求Go 1.19 或更高版本。任何你喜欢的 IDE 或文本编辑器如 VS Code, GoLand。基本的命令行操作知识。项目初始化mkdir mydb cd mydb go mod init github.com/yourusername/mydb项目目录结构规划mydb/ ├── go.mod ├── go.sum ├── cmd/ │ └── mydb/ # 主程序入口 │ └── main.go └── internal/ # 内部包不对外暴露 ├── storage/ # 存储引擎核心 │ ├── btree.go # BTree 实现 │ ├── page.go # 磁盘页管理 │ ├── wal.go # 预写日志 │ └── engine.go # 存储引擎接口与主逻辑 ├── tx/ # 事务管理 │ └── manager.go ├── sql/ # SQL 解析与执行简化版 │ └── parser.go └── meta/ # 元数据管理表、索引信息 └── catalog.go4. 存储管理层磁盘页与文件管理数据库与内存数据结构最大的区别在于它必须持久化。操作系统以“块”为单位进行 IO数据库则抽象出“页”的概念。我们首先实现最底层的页管理。4.1 页Page的设计页是磁盘和内存之间交换数据的基本单位。我们定义一个固定大小的页例如 4KB4096 字节。// internal/storage/page.go package storage import ( encoding/binary errors ) const PageSize 4096 // 4KB type PageID uint64 // Page 表示内存中的一个数据页 type Page struct { ID PageID Data []byte // 大小为 PageSize IsDirty bool // 标识页是否被修改需要写回磁盘 PinCount int // 引用计数用于缓冲池管理 } // NewPage 创建一个新的空页 func NewPage(id PageID) *Page { return Page{ ID: id, Data: make([]byte, PageSize), } } // WriteData 在页的指定偏移量处写入数据 func (p *Page) WriteData(offset int, data []byte) error { if offsetlen(data) PageSize { return errors.New(data exceeds page boundary) } copy(p.Data[offset:], data) p.IsDirty true return nil } // ReadData 从页的指定偏移量处读取数据 func (p *Page) ReadData(offset, length int) ([]byte, error) { if offsetlength PageSize { return nil, errors.New(read beyond page boundary) } return p.Data[offset : offsetlength], nil } // 一些辅助函数用于在页中读写基本类型 func (p *Page) PutUint64(offset int, value uint64) { binary.LittleEndian.PutUint64(p.Data[offset:], value) p.IsDirty true } func (p *Page) GetUint64(offset int) uint64 { return binary.LittleEndian.Uint64(p.Data[offset:]) }4.2 磁盘管理器与缓冲池数据库不可能每次读写都直接操作磁盘文件那样太慢。我们需要一个缓冲池在内存中缓存热点数据页。// internal/storage/disk_manager.go package storage import ( os sync ) // DiskManager 管理数据库文件 type DiskManager struct { file *os.File filePath string mu sync.RWMutex } func NewDiskManager(filePath string) (*DiskManager, error) { file, err : os.OpenFile(filePath, os.O_RDWR|os.O_CREATE, 0666) if err ! nil { return nil, err } return DiskManager{file: file, filePath: filePath}, nil } // ReadPage 从磁盘读取指定页到内存 func (dm *DiskManager) ReadPage(pageID PageID, page *Page) error { dm.mu.RLock() defer dm.mu.RUnlock() offset : int64(pageID) * PageSize _, err : dm.file.ReadAt(page.Data, offset) if err ! nil err.Error() ! EOF { return err } page.ID pageID page.IsDirty false return nil } // WritePage 将内存中的脏页写回磁盘 func (dm *DiskManager) WritePage(page *Page) error { if !page.IsDirty { return nil // 不是脏页无需写入 } dm.mu.Lock() defer dm.mu.Unlock() offset : int64(page.ID) * PageSize _, err : dm.file.WriteAt(page.Data, offset) if err ! nil { return err } // 建议在关键操作后调用 Sync但频繁调用影响性能。通常有 WAL 保证持久性。 // dm.file.Sync() page.IsDirty false return nil } // AllocatePage 分配一个新的页ID例如通过文件大小计算 func (dm *DiskManager) AllocatePage() (PageID, error) { dm.mu.Lock() defer dm.mu.Unlock() stat, err : dm.file.Stat() if err ! nil { return 0, err } // 文件大小必须是 PageSize 的整数倍 newPageID : PageID(stat.Size() / PageSize) // 将文件扩展一页 if err : dm.file.Truncate(int64(newPageID1) * PageSize); err ! nil { return 0, err } return newPageID, nil } // Close 关闭文件 func (dm *DiskManager) Close() error { return dm.file.Close() }缓冲池的实现更为复杂需要实现页的替换策略如 LRU。为了简化我们暂用一个简单的 Map 来缓存页并在内存不足时进行随机替换。在实际项目中你会需要实现一个完整的缓冲池管理器。5. 存储引擎核心BTree 的实现BTree 是关系型数据库索引的基石。我们将实现一个在磁盘上持久化的 BTree。5.1 BTree 节点结构BTree 的节点分为内部节点和叶子节点。它们都存储在Page中。// internal/storage/btree.go package storage const ( InternalNode 1 LeafNode 2 ) // BPlusTreeHeader 存储在文件的第一个页记录树的基本信息 type BPlusTreeHeader struct { RootPageID PageID Order uint16 // 树的阶数每个节点最多有 Order-1 个键 Height uint16 } // NodeHeader 每个 BTree 节点页的头部信息 type NodeHeader struct { NodeType uint8 // InternalNode 或 LeafNode KeyCount uint16 ParentPageID PageID // 对于叶子节点还有一个 NextPageID 指向下一个叶子节点便于范围扫描 NextPageID PageID } // 计算一个页内头部之后可用于存储键值对的空间 func (h *NodeHeader) FreeSpaceOffset() int { return /* NodeHeader 大小 */ int(h.KeyCount)* /* 每个键值对索引的大小 */ }5.2 键的插入与节点分裂这是 BTree 最核心的逻辑。当向一个已满的节点插入新键时需要将其分裂成两个节点并将中间键提升到父节点。// internal/storage/btree.go (续) func (t *BPlusTree) Insert(key []byte, value []byte) error { rootPage, err : t.bufferPool.GetPage(t.header.RootPageID) if err ! nil { return err } defer t.bufferPool.UnpinPage(rootPage.ID, false) // 1. 找到应该插入的叶子节点 leafPage, err : t.findLeaf(rootPage, key) if err ! nil { return err } // 2. 如果叶子节点有空间直接插入 if leafHasSpace(leafPage) { return t.insertIntoLeaf(leafPage, key, value) } // 3. 叶子节点已满需要分裂 // 这是一个简化的分裂过程 newLeafPage, err : t.bufferPool.NewPage() if err ! nil { return err } // 初始化新叶子节点头 // 将原叶子节点一半的键值对移动到新节点 // 更新原叶子节点和新叶子节点的 NextPageID链表指针 // 将新叶子节点的第一个键提升到父节点 // 如果父节点也满了递归分裂可能导致树增高 // ... (具体分裂逻辑较长涉及大量页内数据移动和指针更新) return t.insertIntoParent(parentPage, /* 提升的键 */, newLeafPage.ID) }关键点分裂操作会产生多个脏页原叶子页、新叶子页、父页等这些修改必须在事务中保持原子性这正是 WAL 要解决的问题。5.3 键的查找查找相对简单从根节点开始根据键的大小比较沿着内部节点的指针向下遍历直到叶子节点。func (t *BPlusTree) Get(key []byte) ([]byte, bool, error) { rootPage, err : t.bufferPool.GetPage(t.header.RootPageID) if err ! nil { return nil, false, err } defer t.bufferPool.UnpinPage(rootPage.ID, false) leafPage, err : t.findLeaf(rootPage, key) if err ! nil { return nil, false, err } defer t.bufferPool.UnpinPage(leafPage.ID, false) // 在叶子节点中进行二分查找找到对应的键 idx : t.binarySearchInLeaf(leafPage, key) if idx 0 { return nil, false, nil // 未找到 } // 根据 idx 从叶子页的数据区读取 value value : t.readValueFromLeaf(leafPage, idx) return value, true, nil }6. 崩溃恢复的基石预写日志WAL没有 WAL任何未刷盘的修改在崩溃后都会丢失。WAL 的核心思想是日志先行。6.1 日志记录格式每条日志记录需要包含足够的信息以便在重放时能精确地重构出操作。// internal/storage/wal.go package storage type LogType uint8 const ( LogTypeInsert LogType iota 1 LogTypeUpdate LogTypeDelete LogTypeCommit LogTypeAbort ) type LogRecord struct { LSN uint64 // 日志序列号全局递增 TxID uint64 // 事务ID Type LogType PageID PageID Offset uint16 // 在页内的偏移量 OldData []byte // 用于 UNDO (如回滚) NewData []byte // 用于 REDO (如重放) Checksum uint32 // 用于检测日志是否损坏 } // Serialize 将日志记录序列化为字节流以便写入文件 func (lr *LogRecord) Serialize() []byte { buf : make([]byte, 0) // 按顺序将各个字段以二进制形式写入 buf // 例如binary.LittleEndian.PutUint64(buf, lr.LSN) // 注意处理变长字段 OldData 和 NewData return buf } // Deserialize 从字节流反序列化出日志记录 func DeserializeLogRecord(data []byte) (*LogRecord, error) { // ... 反向解析 }6.2 日志管理器日志管理器负责将日志记录顺序追加到日志文件并在适当的时候触发“检查点”以截断旧日志。// internal/storage/wal.go (续) type LogManager struct { logFile *os.File currentLSN uint64 activeTxMap map[uint64][]uint64 // 事务ID - 该事务产生的LSN列表 mu sync.Mutex } func (lm *LogManager) AppendLog(txID uint64, logType LogType, pageID PageID, offset uint16, oldData, newData []byte) (uint64, error) { lm.mu.Lock() defer lm.mu.Unlock() lsn : lm.currentLSN 1 record : LogRecord{ LSN: lsn, TxID: txID, Type: logType, PageID: pageID, Offset: offset, OldData: oldData, NewData: newData, } data : record.Serialize() // 1. 先持久化日志记录 _, err : lm.logFile.Write(data) if err ! nil { return 0, err } // 强烈建议每次写日志后同步确保落盘。这是 WAL 保证持久性的关键。 err lm.logFile.Sync() if err ! nil { // 日志写失败整个操作应该失败 return 0, err } // 2. 日志持久化成功后再更新内存状态 lm.currentLSN lsn if _, ok : lm.activeTxMap[txID]; !ok { lm.activeTxMap[txID] []uint64{} } lm.activeTxMap[txID] append(lm.activeTxMap[txID], lsn) return lsn, nil } // FlushPageToDisk 在将脏页刷盘前必须确保其对应的所有日志记录都已持久化。 // 这通过比较页的 LSN最后一次修改该页的日志LSN和 logManager 的 flushedLSN 来实现。 func (lm *LogManager) FlushPageToDisk(page *Page) error { // 检查 page.LastLSN lm.flushedLSN // 如果不满足需要先强制刷日志。 // ... return nil }6.3 恢复流程数据库启动时会进入恢复流程func (s *StorageEngine) Recover() error { // 1. 分析阶段扫描日志找出崩溃时未完成的事务只有 BEGIN 没有 COMMIT/ABORT和脏页信息。 // 2. 重做阶段从最近的检查点开始重放所有日志包括已提交和未提交事务将数据页恢复到崩溃前的状态。 // 3. 撤销阶段回滚所有未提交的事务根据日志中的 OldData。 // 恢复完成后数据库处于一致状态。 }这个流程保证了Atomicity和Durability。即使数据页本身没有刷盘只要日志刷盘了恢复后数据就不会丢失。7. 事务与并发控制简易锁管理器为了支持多个客户端同时操作我们需要管理并发。这里实现一个最简单的行级排他锁。// internal/tx/manager.go package tx import ( sync ) type LockType int const ( SharedLock LockType iota ExclusiveLock ) type LockManager struct { mu sync.Mutex lockMap map[string]map[uint64]LockType // key: 锁定的资源标识如 table:row:1, value: 事务ID - 锁类型 waitMap map[uint64][]uint64 // 事务ID - 它正在等待哪些事务 } func (lm *LockManager) AcquireLock(txID uint64, resource string, lockType LockType) bool { lm.mu.Lock() defer lm.mu.Unlock() holders, exists : lm.lockMap[resource] if !exists { lm.lockMap[resource] map[uint64]LockType{txID: lockType} return true } // 检查锁兼容性 for holderID, holderType : range holders { if holderID txID { // 同一个事务可以锁升级如 S - X // ... 处理锁升级逻辑 return true } if !lockCompatible(holderType, lockType) { // 锁冲突将当前事务加入等待队列 lm.waitMap[txID] append(lm.waitMap[txID], holderID) return false // 获取锁失败需要等待 } } // 无冲突获取锁成功 holders[txID] lockType return true } func (lm *LockManager) ReleaseLock(txID uint64, resource string) { lm.mu.Lock() defer lm.mu.Unlock() if holders, ok : lm.lockMap[resource]; ok { delete(holders, txID) if len(holders) 0 { delete(lm.lockMap, resource) } } // 释放锁后可能需要唤醒等待这个资源的事务 // ... 检查 waitMap唤醒可以继续的事务 }在存储引擎执行PUT或DELETE前需要先通过锁管理器获取对应 Key 的排他锁。GET操作可以获取共享锁如果实现的话。这保证了基本的隔离性。8. 从键值到 SQL一个简单的解析外壳最后我们提供一个简单的 SQL 接口让我们的数据库看起来更像传统的数据库。// internal/sql/parser.go package sql import ( strings ) // 一个极其简单的解析器仅用于演示 func ParseAndExecute(storageEngine storage.Engine, sql string) ([]string, error) { sql strings.TrimSpace(sql) upperSQL : strings.ToUpper(sql) switch { case strings.HasPrefix(upperSQL, INSERT INTO): // 解析表名和 VALUES 部分 // 例如INSERT INTO users (id, name) VALUES (1, Alice) // 将其转化为对底层存储引擎的 PUT 操作 // key 可以是 table:users:primary_key:1 // value 是序列化后的行数据 {id:1, name:Alice} // return storageEngine.Put(key, value) case strings.HasPrefix(upperSQL, SELECT): // 解析 FROM 和 WHERE 部分简化只支持主键查询 // 例如SELECT * FROM users WHERE id 1 // 生成 key table:users:primary_key:1 // value, found, err : storageEngine.Get(key) // 将 value 反序列化并格式化为结果集返回 default: return nil, fmt.Errorf(unsupported SQL: %s, sql) } return nil, nil }9. 运行与验证启动你的数据库现在让我们将各个模块组合起来并提供一个简单的交互式命令行。// cmd/mydb/main.go package main import ( bufio fmt os strings github.com/yourusername/mydb/internal/storage github.com/yourusername/mydb/internal/sql ) func main() { fmt.Println(Starting MyDB...) // 1. 初始化存储引擎包含磁盘管理、缓冲池、BTree、WAL engine, err : storage.NewEngine(./mydb.data) if err ! nil { panic(err) } defer engine.Close() // 2. 启动恢复流程 err engine.Recover() if err ! nil { panic(err) } fmt.Println(Recovery completed.) // 3. 进入简单的 REPL (Read-Eval-Print Loop) reader : bufio.NewReader(os.Stdin) for { fmt.Print(mydb ) input, _ : reader.ReadString(\n) input strings.TrimSpace(input) if input { continue } if strings.ToUpper(input) EXIT { fmt.Println(Bye!) break } // 4. 解析并执行 SQL results, err : sql.ParseAndExecute(engine, input) if err ! nil { fmt.Printf(ERROR: %v\n, err) } else if results ! nil { for _, row : range results { fmt.Println(row) } } else { fmt.Println(Query OK.) } } }运行与测试编译并运行go run cmd/mydb/main.go在mydb提示符下输入简易 SQLCREATE TABLE users (id INT PRIMARY KEY, name TEXT); -- 我们的解析器可能不支持需要预先定义元数据 INSERT INTO users VALUES (1, Alice); SELECT * FROM users WHERE id 1;注由于我们的 SQL 解析器极其简化你可能需要直接调用底层的engine.Put和engine.Get进行测试。测试崩溃恢复在插入数据后直接CtrlC终止程序。然后重新启动程序观察恢复日志并尝试读取刚才插入的数据应该能成功读取。10. 常见问题与排查思路在实现和运行这样一个系统时你会遇到各种问题。以下是一些典型问题及其排查方向问题现象可能原因排查方式解决方案插入数据后重启数据丢失。WAL 机制未正确实现或日志未强制刷盘。1. 检查wal.go中AppendLog后是否调用了file.Sync()。2. 检查恢复流程是否被正确调用和执行。确保每条日志在返回成功前都已持久化到磁盘。并发写入时出现数据覆盖或读取到中间状态。锁管理器未工作或锁粒度不对。事务未正确隔离。1. 在PUT/GET前后打印锁获取和释放日志。2. 编写并发测试用例模拟交错的读写操作。检查锁兼容性矩阵确保写操作持有排他锁。考虑实现更完善的 MVCC 替代简单的锁。随着数据量增加插入和查询性能急剧下降。BTree 节点分裂频繁树变得不平衡。缓冲池太小导致大量磁盘 IO。1. 打印树的高度和节点填充率。2. 监控缓冲池的命中率。调整 BTree 的阶数每个节点的容量。增加缓冲池大小。考虑实现 LRU 等更好的页面淘汰算法。错误提示no database selected或corrupt database。元数据如 Catalog损坏或未初始化。存储文件头信息损坏。1. 检查启动时是否成功读取了存储文件的头几个页如 BTree 根页。2. 使用十六进制查看器检查数据文件的前几 KB。实现更健壮的元数据管理和文件头校验和Checksum。在打开文件时进行一致性验证。CPU 或 IO 成为瓶颈如网络热词所示。锁竞争激烈大量线程在等待。日志同步 (fsync) 操作过于频繁。查询未使用索引导致全表扫描。1. 使用 profiling 工具如pprof分析 CPU 热点。2. 使用系统工具如iostat,vmstat监控 IO。3. 分析慢查询或高锁等待的日志。优化锁策略减小锁粒度使用读写锁。组提交日志减少fsync调用次数。确保查询条件能命中索引。11. 最佳实践与深入方向通过这个项目你已经走过了数据库存储引擎最核心的路径。为了将其从一个“玩具”提升到接近“工业级”的理解你可以考虑以下深入方向实现真正的 MVCC用数据版本号如事务ID和回滚段来代替简单的排他锁这是实现READ COMMITTED或REPEATABLE READ隔离级别的关键。优化缓冲池Buffer Pool实现完整的 LRU/K 淘汰算法、预读机制和脏页刷新后台线程。支持多种数据类型和索引目前我们只处理了[]byte。可以增加对整数、浮点数、字符串等类型的支持并实现辅助索引二级索引。实现查询优化器即使是单表查询也可以实现基于成本的优化比如选择使用哪个索引或者是否进行全表扫描。网络层与协议实现一个简单的 MySQL 或 Redis 协议兼容层使其能被标准客户端连接。测试与基准测试编写全面的单元测试、集成测试并使用 YCSB 等基准测试工具评估性能。记住这个项目的价值不在于结果而在于过程。每当你遇到一个具体问题比如“为什么我的 BTree 在随机写入时性能很差”去阅读 LevelDB/RocksDB 的源码、MySQL 的 InnoDB 文档或相关论文对比你的实现你都会对数据库有更深一层的理解。当你再回到日常工作中面对一个缓慢的查询、一个诡异的死锁或一个恢复失败告警时你脑海中将不再是一片空白。你会立刻联想到 BTree 的查找路径、WAL 的刷盘时机、MVCC 的快照版本从而能够提出直指核心的排查假设和优化方案。这种从内到外理解一个核心系统组件的能力正是资深工程师与普通开发者的分水岭。