1. 先搞清楚学内核到底是在学什么1.1 从一条SQL的旅程开始建立全局观刚接触PostgreSQL内核的时候我犯过一个大错直接打开源码目录对着几千个C文件一头扎进去。结果一个月过去连src/backend/下面有哪些模块都没记住反而把热情消耗光了。后来一个搞数据库内核多年的朋友点了我一句先别管具体代码先把“一条SQL从发给PostgreSQL到返回结果中间经过了哪些模块”这条主线走通。这才算真正入了门。一条最简单的SELECT * FROM t WHERE id 1在内核里要经过这么几站前端协议解析客户端发来的文本协议或二进制协议被src/backend/libpq/里的代码接住解析出消息内容词法语法解析src/backend/parser/把SQL文本转成词法单元再生成语法树Parse Tree分析与重写分析器对语法树做语义检查重写器根据规则视图、触发器规则把查询树改写计划生成优化器src/backend/optimizer/基于统计信息生成多个候选执行计划挑一个代价最小的执行执行器src/backend/executor/按照计划树逐节点执行真正去访问堆表、索引、计算表达式事务与存储执行过程中事务管理器记录日志存储模块用缓冲区缓存页最后把结果集返回给客户端。看到没有这其实是一条很清晰的流水线。学内核的第一阶段不是学会某个算法的细节而是把这条流水线上“谁负责什么、谁调用谁、数据长什么样”搞清楚。这样后面读代码时每个文件在你眼里都有自己的位置而不是一堆孤立的C文件。1.2 内核学习路线源码、文档、实验三线并进很多人学内核只啃源码这是效率最低的方式。我建议三线并进源码是主线但要有目的地读不是为了“读完”而读官方文档和开发者文档比如PostgreSQL的Wiki里的开发专题页是第二条辅线用来理解模块的设计意图和演进历史实验验证是第三条线也是容易被低估的一条。改一行代码、重新编译、跑个查询看效果比读十篇分析文章印象都深。我自己的习惯是每学一个模块先花半小时读官方设计文档和相关READMEPostgreSQL源码树里每个子系统目录下基本都有README或注释极其详细的头文件再花一小时带着问题去读源码的关键路径最后强制自己写一个小实验或者调试Demo去验证一个机制。这套流程走完一个知识点才算真正是自己的。读源码时还有一个原则我很认同先读头文件再读实现。“头文件里藏着数据结构定义和接口声明读完头文件你是站在设计者视角看这个模块直接读实现你是站在实现者视角跟着代码跑。”绝大多数关键设计意图都写在注释丰富的头文件里比如src/include/storage/bufmgr.h、src/include/access/heapam.h注释写得比很多技术博客都清楚。2. 内核架构的总纲进程架构与内存模型2.1 进程架构一主多从各司其职PostgreSQL用的是多进程架构一个主进程加一堆辅助进程这和MySQL的多线程架构有本质区别。多进程的好处是单个后台进程崩溃不影响整个数据库坏处是进程间通信成本和上下文切换开销更高。理解这个架构是理解内核一切行为的基础。主进程postmaster是整个实例的“大管家”它负责监听端口接新连接、创建后端进程、在子进程崩溃时做清理并重启辅助进程。你通过pg_ctl start拉起来的那个进程就是它。连接进来后postmaster会fork()一个后端进程backend来服务这条连接。这个进程就是执行你SQL的主体它维护了会话级的内存上下文、查询计划缓存、事务状态。一个连接一个进程这就是PostgreSQL并发模型的根基。辅助进程则是各个“工程队”checkpointer负责周期性把脏页刷到磁盘bgwriter预先把脏页写出去以减少checkpointer压力walwriter负责把WAL日志落盘autovacuum负责清理死元组和更新统计信息stats collector收集统计信息logical replication launcher管理逻辑复制。每学一个辅助进程都可以问自己三个问题它什么时候启动它什么时候干活它不干活会有什么后果以checkpointer为例它默认每5分钟或者积累到一定WAL量就触发一次检查点。检查点的意义是告诉恢复过程“在这个点之前的数据已经落盘了恢复只需要从检查点之后的重做日志开始”。如果checkpointer坏了系统不会立刻崩溃但崩溃恢复时间会越来越长因为要重放越来越多的日志。2.2 共享内存与本地内存数据的流转中枢PostgreSQL启动时会根据配置参数创建一大块共享内存所有后端进程都映射到同一块物理内存。这块共享内存主要包含以下结构区域用途关键参数Buffer Pool缓存数据页这是数据库读写性能的核心shared_buffersWAL Buffer暂存待写入的WAL日志记录wal_buffersClogCommit Log记录每个事务的提交状态固定大小、随事务增长锁表管理行锁、表锁、咨询锁等max_locks_per_transaction进程间通信结构信号、闩锁、快速通知等由内部机制管理这里我特别想说shared_buffers的默认值问题。很多初学者第一次看配置时觉得8MB太小了直接改成16GB结果系统启动失败或者频繁换页。这里有个内核层面的原因shared_buffers是共享内存在启动时用shmget()或mmap映射到固定地址每个buffer管理结构BufferDesc及其associated的锁需要预分配。改大了之后内核可能需要调整SHMMAX参数。更重要的是shared_buffers不是越大越好它还涉及与操作系统页缓存的协同、检查点刷盘压力等问题需要跟checkpoint、bgwriter的参数一起权衡。我一般建议先用默认值熟悉机制再根据实际工作负载逐步调整。每一个数据页在共享缓冲区里对应一个BufferDesc结构里面记录了页的状态空闲、干净、脏、引用计数、使用计数、锁信息。后端进程读写一个页的路径是先查buffer table用page的relfilenodeblock number做hash找到对应的buffer加锁读页或写页最后释放锁并标记脏页。这套路径几乎每个查询都要走所以是内核学习的一个绝对重点。2.3 缓冲区置换当内存不够用时怎么办缓冲区不是无限大的。shared_buffers满的时候需要一个脏页换出去才能读入新页。PostgreSQL的置换算法是clock sweep时钟扫描这个机制在src/backend/storage/buffer/freelist.c里。简单说每个BufferDesc有个usage_count字段每次访问一个页时如果count小于特定上限就加1。当需要腾出缓冲区时clock指针沿buffer环形链表扫描遇到usage_count为0的干净页直接复用非0的就减1再继续扫。这样一个循环下来那些频繁访问的页因为usage_count保持在较高水平不容易被换出。这本质上是一种近似LRU算法延迟更新让高频页能“幸存”。我在实验环境里验证过一次对一张1亿行的大表做全表扫描时把每页的usage_count打出来看发现顺序扫描的页是“用完即弃”的——因为全表扫描只要一次访问clock sweep很快就把它们换出去了。而一个小表被反复join时那些页的usage_count会慢慢涨上去留在缓冲池里。这个实验让我理解了为什么同样是表有的页页能“住在内存里”有的页来来走走——这是算法设计的必然结果不是玄学。3. 事务、MVCC与WAL数据库内核的灵魂三件套3.1 事务ID、CLOG与快照原来事务状态是这样记录的PostgreSQL里每个事务都会分配一个事务IDXID它是单调递增的32位整数。但这个ID不是分配了就一直背着的——在真正修改数据之前事务可以处于“延迟分配”状态因为只读事务如果也分配XID会白白消耗事务号还导致vacuum清理受限。这是PostgreSQL一个精妙的小优化。事务状态记录在哪不是记在数据页里而是记在一个叫CLOGCommit Log的共享内存结构里落盘到pg_xact目录。CLOG按页组织每页能记录8192个事务的状态每个事务的状态用2个bit表示IN_PROGRESS、COMMITTED、ABORTED、SUBTRANSACTION。为什么这样设计因为判断一个元组是否可见最核心的问题就是“插入这个元组的事务提交了吗”。而CLOG用固定大小的bits来表示查找速度非常快。学习CLOG时可以做个小实验查看pg_current_xact_id()的值然后执行一条查询观察CLOG页的变化。我做过一个实验用一个长事务把一个表的数据改了但不提交然后去检查pg_xact_status()函数能看到这个事务ID的状态从IN_PROGRESS变成COMMITTED或ABORTED。这个直观实验让我彻底明白了事务可见性判断的根基。3.2 元组可见性规则MVCC到底是怎么做到的MVCC多版本并发控制是PostgreSQL最核心的设计之一。它不像很多数据库那样用回滚段来提供旧版本数据而是直接在堆表里保留多个版本每个版本的元组头里记录插入它的xmin、删除它的xmax。判断一个元组是否对当前事务可见核心逻辑在HeapTupleSatisfiesMVCC这个函数里。这是一段绕不过去的关键代码也是面试高频题。简化一下规则大致是如果元组的xmin是当前事务自己且xmax无效则可见如果xmin对应的事务已提交且xmax无效或对应的事务未提交则可分情况判断如果xmax对应的事务已提交说明元组已被删除不可见如果xmin对应的事务还在进行中则不可见。这套规则解决的并发场景是读不阻塞写、写不阻塞读。这也是为什么PostgreSQL能支持极高的并发读写的根基。但代价是死元组dead tuple需要automated vacuum来清理。如果vacuum跟不上表会膨胀索引会低效这是一套机制的两个侧面。我学习这个规则时用了一个特别土的办法写一个C扩展直接打印元组的t_xmin和t_xmax字段然后在不同隔离级别下执行不同的并发事务组合观察这些字段的变化。虽然PostgreSQL有现成的pageinspect扩展可以看页面的原始数据但自己动手打印更能加深理解。3.3 WAL机制崩溃后凭什么还能恢复数据数据一致性不能只靠“刷盘”解决。PostgreSQL的做法是WALWrite-Ahead Logging数据页的修改需要先记录日志日志落盘后才能把脏页刷出去。这样即使数据库崩溃也能通过重放WAL日志恢复到崩溃前的状态。WAL的核心内容在src/backend/access/transam/xlog.c里。每次事务提交walwriter要把WAL Buffer里缓存到该事务结束点的日志刷到磁盘的pg_wal目录。一个常见误解是“WAL每次提交都fsync性能肯定很差”。确实每次事务提交都要fsync这是保证持久化的底线但内核都做了很多优化group commit把多个并发事务的提交一起fsync、wal_buffers预处理、检查点削峰等。我在实验室里用pgbench压测时对比过fsyncon和fsyncoff的性能差异。off时TPS能高出一个数量级但这只适合非核心场景。这个对比实验很有价值能让你直观感受“持久性是有性能代价的”这句话的分量。需要深入理解的还包括LSNLog Sequence Number机制。每个数据页头部会记录最后一次修改它的WAL记录的LSN恢复时如果日志记录的LSN小于页面上记录的LSN说明这个修改已经刷盘了对应日志可以跳过。这就避免了崩溃恢复时重复应用日志。这套设计思路在很多存储系统里都能看到学透了可以延伸到其他分布式数据库的复制、恢复机制。4. 查询引擎从语法树到执行计划4.1 解析与语法分析SQL是怎么变成“计算机能懂”的结构的SQL文本进入内核后的第一站是解析器。PostgreSQL用flex和bison生成词法分析器和语法分析器对应文件在src/backend/parser/下词法在scan.l语法在gram.y。bison的语法规则文件非常大有两三万个规则支持了丰富的SQL语法。语法分析完成后生成Parse Tree解析树里面的节点类型是SelectStmt、InsertStmt这类结构体它们定义在src/include/nodes/parsenodes.h里。这棵树虽然已经结构化了但还不能直接执行因为里面还带着表名、列名这些符号而不是对象OID也没做权限和语义检查。接着是分析Analyze和重写Rewrite阶段。分析阶段会把表名解析成Relation OID把列名解析成属性编号把函数的字符串名称解析成函数OID同时做类型检查。重写阶段则负责视图展开、规则系统处理。如果你创建过一个视图这个阶段会把视图的定义SQL替换到查询树里形成一棵“真实”的查询树。如果在这一步出错你会看到“relation ... does not exist”或“column ... does not exist”的报错。这个阶段出错的查询根本不会进入优化器。理解这一点对排查“为什么我的SQL报对象不存在而同事的不报”之类的问题很有帮助。4.2 查询优化与执行代价模型是怎么一步步选出计划的优化器是很多人觉得最难啃的部分。它的核心思路是根据系统表里的统计信息pg_statistic由ANALYZE收集估算每个执行计划节点的行数和代价然后枚举可能的连接顺序、访问路径、连接算法选择总代价最小的计划。PostgreSQL的优化器分两个层次planner生成总体计划和subquery等模块进一步处理子查询。连接算法主要有三种嵌套循环连接、哈希连接、归并连接。分别适用不同场景小表连接小表、等值连接的大表对大表、排序数据的有序连接。优化器不是死板地挑一种而是对每个连接对都生成可能的路径按代价公式比较。执行器拿到Plan Tree后从顶层节点开始递归执行。每种节点对应一个执行函数SeqScan节点调用nodeSeqscan.c的ExecSeqScanHashJoin节点调用nodeHashjoin.c的ExecHashJoin。每个节点执行时都遵循标准的open/next/close流程用元组TupleTableSlot在节点间传递。这种Volcano式模型的特点是每执行一次next就产生一行结果内存占用小但函数调用开销高。我在做性能分析时经常用EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)来看每个节点的实际返回行数、耗时和缓冲命中情况。有一次一条两表join查询跑得很慢EXPLAIN显示优化器估算的行数比实际少了两个数量级原因是没有及时ANALYZE统计信息严重过期。这个案例能帮你理解为什么内核里统计信息模块举足轻重也说明优化器不是你写错查询的“背锅对象”很多慢查询根源在统计信息太旧。4.3 索引访问方法为什么主键查询那么快索引模块是内核里另一个学习重点。PostgreSQL的索引通过访问方法Access Method抽象接口来插拔最常用的是B-tree索引在src/backend/access/nbtree/目录下。别的还有Hash索引、GIN索引全文检索和数组、GiST索引空间和通用树等。B-tree索引用的是经典B树结构内节点只存放键值用于路由叶子节点存放实际键值和对应元组的TID块号偏移。在B-tree里面查找一个键从根节点二分向下经过三五层就能定位到叶子页再在页内二分。对于一个有几百万行的表主键等值查询往往只需四五次页面读取这是它快的关键。学习B-tree索引时有个容易忽略但很重要的部分是“索引的并发控制”。PostgreSQL的B-tree并发控制不是简单的加锁整棵树而是使用了类似“读写锁分离且向下搜索时允许短暂不一致”的算法下行搜索时加低级别锁找到合适位置后再升级到更严格的锁来插入或删除键值。这里面还涉及页分裂时的兄弟页链接和并发搜索的协调。以前我总以为B-tree就是背个B树的定义就行了其实内核里的并发细节比教科书复杂得多。用pageinspect扩展查看索引页内容是个不错的实验先建一张有主键的表插入一些数据然后用pageinspect查看索引页的元组和键值布局。我做过一次后对B树“键值物理有序”的理解立刻从抽象变成了具体。5. 实操学习法环境搭建、源码调试与验证实验5.1 本地环境搭建最快能在代码里跑通SQL的环境我自己的学习环境配置比较轻量在普通开发机上直接下载PostgreSQL源码包configure时加--enable-debug --enable-cassert --prefix$HOME/pgsql然后make、make install。--enable-debug保留调试符号--enable-cassert开启大量断言检查能在开发调试时提早暴露问题。配置完成后初始化一个数据目录启动一个临时实例cd ~/pgsql/bin ./initdb -D ~/pgdata ./pg_ctl -D ~/pgdata -l /tmp/pg.log start createdb testdb psql testdb这套环境的好处是随时可以用gdb附加到后端进程上进行调试。注意不要在生产环境的数据库上做这些实验用独立的本地实例练习出了问题直接重新initdb即可。如果想深入调试推荐用gdb 一个专门的调试脚本。PostgreSQL源码里有个src/tools/gdb目录提供了打印节点结构、元组信息的辅助函数。我经常在gdb里打断点后执行attach到一个后端进程然后运行一条SQL看它怎么一步步进入ExecSeqScan、heap_getnext这些函数。5.2 源码阅读顺序与工具三个月能读到哪里如果有人问我源码阅读顺序我会给出这样一个参考路径这是我流了很多弯路后整理出来的进程与内存先入门src/backend/main/main.c、src/backend/access/transam/xlog.c只读入口和关键路径、src/backend/storage/buffer/bufmgr.c事务与MVCCsrc/backend/access/transam/README、src/backend/access/heap/heapam.c可见性判断、src/backend/access/transam/clog.c查询引擎先读src/backend/parser/gram.y的语法结构简版再读src/backend/optimizer/plan/planner.c、src/backend/executor/execMain.c存储管理与索引src/backend/storage/page/README、src/backend/access/nbtree/README。读的时候建议配合Git历史。PostgreSQL是活跃社区每个提交都链接着社区邮件列表的讨论很多设计背后的取舍都在邮件列表里讲得很透。用git log --oneline -- 文件名看某个文件的历史能发现很多“为什么这么做”的答案。工具方面除了gdb我还会用cscope、rgripgrep做代码搜索用CLion或VSCode加上插件做代码跳转。个人体验是CLion的索引处理大型C项目更顺手但VSCode轻量免费对大多数人也够用。关键不是工具多好而是你要习惯带着“这个函数被谁调用、这个字段表示什么含义”的问题去读而不是逐行读。5.3 用实验验证机制一个小技巧抵得上十篇文档遇到晦涩的机制直接看代码容易绕晕我的办法是写一个小Demo或SQL去触发它然后打断点看执行路径。举两个我经常做的实验实验一验证MVCC的可见性函数流程。开两个psql会话一个会话更新一行但不提交另一个会话查询同一行。然后在HeapTupleSatisfiesMVCC函数下断点观察它读取的事务状态是IN_PROGRESS还是COMMITTED。你会发现当使用默认的读已提交隔离级别时每个语句都会获取新快照所以能看到已提交的新版本而在可重复读隔离级别下同一事务的所有语句共用快照所以看不到新提交的版本。这个实验极大加深了对快照和隔离级别的理解。实验二验证缓冲区置换。把shared_buffers设成很小的值比如64MB然后用一个脚本反复查询一张大表观察Buffer Pool的命中率和clock scan的移动情况。配合pg_buffercache扩展能看到哪些页被缓存在哪里、引用计数是多少。这个实验能直观地了解shared_buffers不足时的换页风暴现象。这些实验都不复杂但做一次比自己空想十遍强。内核学习最大的误区是只看不练。6. 典型问题与避坑指南6.1 复现崩溃场景用core dump定位问题学内核不可避免会碰到“自己改的代码把数据库搞崩了”的情况。第一次遇到时很可能连错误都看不懂。我的建议是先把core dump配置好ulimit -c unlimited echo /tmp/core_%e_%p /proc/sys/kernel/core_pattern崩溃后gdb解析coregdb ~/pgsql/bin/postgres /tmp/core_postgres_12345 bt常见原因无非几种指针没判空、内存上下文释放顺序错了、缓冲页锁没释放。PostgreSQL内核里大量使用palloc内存上下文一个常见错误是pg_free了不属于当前上下文的指针或者context脱离后还去访问对象。这类问题用valgrind或者开启--enable-cassert的assertion往往能在早期暴露。6.2 改了源码后重新编译的注意事项PostgreSQL的编译系统是基于Make的如果只改一个文件理论上只需要重编相关目标文件但实际使用中经常出现“改了头文件但目标文件没重新编译”导致行为诡异的问题。稳妥做法是make clean make -j8重新编译。代价是耗时但比排查诡异问题省时间。另外修改源码前先确保环境隔离。最怕的情况是你改了源码但启动的二进制还是旧的系统安装版因为PATH里面先找到的是系统目录里的PostgreSQL。检查方式是which postgres、psql --version确保指向的是自己编译目录的二进制。我踩过这个坑后每次编译安装完都会立刻执行~\/pgsql/bin/postgres --version确认。6.3 几个容易踩进去的学习误区误区一试图一次性读完源码。内核代码量大几十万行起步没有人能“读完”。正确做法是“按场景精读”比如要回答“vacuum如何清理死元组”只读vacuumlazy.c和heapam.c的相关路径即可不要为了读完而读。误区二跳过GLgeneral概念直接上代码。如果没有操作系统、编译原理、数据结构基础建议先补充一下不知道什么是页缓冲、什么是B树、什么是LRU读源码会寸步难行。建议先看一本系统级的数据库教材再回到源码。误区三不写实验只看博客。读再多别人的分析文章都不如自己跑通一次实验。我有一次为了搞清楚LockAcquire和LockRelease的逻辑写了一个模拟并发事务的小脚本反复制造锁等待场景用pg_locks视图观察锁状态变化。这个过程很慢但三个月后我对锁机制的印象依然清晰。误区四忽略代码注释里的历史原因。源码注释里经常会写“This is ugly, but ...”“Unfortunately ...”这种话。这些地方往往就是设计妥协的现场对理解“为什么是现在这样”特别有帮助。我从来不会跳过这些注释反而会专门搜索这类关键词。7. 一些个人体会学习PostgreSQL内核不是一蹴而就的事更像是一条需要持续投入的工艺线。从第一个gdb断点打在main.c上到第一次能独立分析一个查询的性能瓶颈中间可能要经历几个月甚至更长的时间。这个过程里最重要的不是记忆某个函数的细节而是逐步建立起对数据库系统的直觉一条查询在启动到返回之间要做哪些事哪些环节是性能瓶颈哪些机制在幕后保障一致性哪些配置参数影响哪条路径。如果只能给一条建议我会建议每一个想学内核的人尽早动手写实验哪怕实验本身很小。“在源码里打断点亲自走一遍执行路径”和“看别人分析文章”是两个层次的理解。前者会让你真正成为内核的“使用者之内的理解者”后者只能让你停留在“旁观者”的层面。另外PostgreSQL社区是一个非常开放的集体。邮件列表的讨论涵盖了从新手提问到资深开发者设计回顾的全部话题。遇到问题时先搜邮件列表再搜Stack Overflow最后看源码。这个顺序能节省大量时间。内核学习的终点不是“把所有模块读完”而是“遇到新问题时知道去哪里找答案并能通过源码定位到具体实现”。具备这种能力后不管是做数据库运维、内核开发还是调优都会比只会用外部文档的同行有更深一层的判断力。这条路上没有捷径但每一步都不会白走。 
长河君 · 2026/10/21 15:16:25 · 阅读 1.2k PostgreSQL内核学习路线：从SQL旅程到源码调试
1. 先搞清楚学内核到底是在学什么1.1 从一条SQL的旅程开始建立全局观刚接触PostgreSQL内核的时候我犯过一个大错直接打开源码目录对着几千个C文件一头扎进去。结果一个月过去连src/backend/下面有哪些模块都没记住反而把热情消耗光了。后来一个搞数据库内核多年的朋友点了我一句先别管具体代码先把“一条SQL从发给PostgreSQL到返回结果中间经过了哪些模块”这条主线走通。这才算真正入了门。一条最简单的SELECT * FROM t WHERE id 1在内核里要经过这么几站前端协议解析客户端发来的文本协议或二进制协议被src/backend/libpq/里的代码接住解析出消息内容词法语法解析src/backend/parser/把SQL文本转成词法单元再生成语法树Parse Tree分析与重写分析器对语法树做语义检查重写器根据规则视图、触发器规则把查询树改写计划生成优化器src/backend/optimizer/基于统计信息生成多个候选执行计划挑一个代价最小的执行执行器src/backend/executor/按照计划树逐节点执行真正去访问堆表、索引、计算表达式事务与存储执行过程中事务管理器记录日志存储模块用缓冲区缓存页最后把结果集返回给客户端。看到没有这其实是一条很清晰的流水线。学内核的第一阶段不是学会某个算法的细节而是把这条流水线上“谁负责什么、谁调用谁、数据长什么样”搞清楚。这样后面读代码时每个文件在你眼里都有自己的位置而不是一堆孤立的C文件。1.2 内核学习路线源码、文档、实验三线并进很多人学内核只啃源码这是效率最低的方式。我建议三线并进源码是主线但要有目的地读不是为了“读完”而读官方文档和开发者文档比如PostgreSQL的Wiki里的开发专题页是第二条辅线用来理解模块的设计意图和演进历史实验验证是第三条线也是容易被低估的一条。改一行代码、重新编译、跑个查询看效果比读十篇分析文章印象都深。我自己的习惯是每学一个模块先花半小时读官方设计文档和相关READMEPostgreSQL源码树里每个子系统目录下基本都有README或注释极其详细的头文件再花一小时带着问题去读源码的关键路径最后强制自己写一个小实验或者调试Demo去验证一个机制。这套流程走完一个知识点才算真正是自己的。读源码时还有一个原则我很认同先读头文件再读实现。“头文件里藏着数据结构定义和接口声明读完头文件你是站在设计者视角看这个模块直接读实现你是站在实现者视角跟着代码跑。”绝大多数关键设计意图都写在注释丰富的头文件里比如src/include/storage/bufmgr.h、src/include/access/heapam.h注释写得比很多技术博客都清楚。2. 内核架构的总纲进程架构与内存模型2.1 进程架构一主多从各司其职PostgreSQL用的是多进程架构一个主进程加一堆辅助进程这和MySQL的多线程架构有本质区别。多进程的好处是单个后台进程崩溃不影响整个数据库坏处是进程间通信成本和上下文切换开销更高。理解这个架构是理解内核一切行为的基础。主进程postmaster是整个实例的“大管家”它负责监听端口接新连接、创建后端进程、在子进程崩溃时做清理并重启辅助进程。你通过pg_ctl start拉起来的那个进程就是它。连接进来后postmaster会fork()一个后端进程backend来服务这条连接。这个进程就是执行你SQL的主体它维护了会话级的内存上下文、查询计划缓存、事务状态。一个连接一个进程这就是PostgreSQL并发模型的根基。辅助进程则是各个“工程队”checkpointer负责周期性把脏页刷到磁盘bgwriter预先把脏页写出去以减少checkpointer压力walwriter负责把WAL日志落盘autovacuum负责清理死元组和更新统计信息stats collector收集统计信息logical replication launcher管理逻辑复制。每学一个辅助进程都可以问自己三个问题它什么时候启动它什么时候干活它不干活会有什么后果以checkpointer为例它默认每5分钟或者积累到一定WAL量就触发一次检查点。检查点的意义是告诉恢复过程“在这个点之前的数据已经落盘了恢复只需要从检查点之后的重做日志开始”。如果checkpointer坏了系统不会立刻崩溃但崩溃恢复时间会越来越长因为要重放越来越多的日志。2.2 共享内存与本地内存数据的流转中枢PostgreSQL启动时会根据配置参数创建一大块共享内存所有后端进程都映射到同一块物理内存。这块共享内存主要包含以下结构区域用途关键参数Buffer Pool缓存数据页这是数据库读写性能的核心shared_buffersWAL Buffer暂存待写入的WAL日志记录wal_buffersClogCommit Log记录每个事务的提交状态固定大小、随事务增长锁表管理行锁、表锁、咨询锁等max_locks_per_transaction进程间通信结构信号、闩锁、快速通知等由内部机制管理这里我特别想说shared_buffers的默认值问题。很多初学者第一次看配置时觉得8MB太小了直接改成16GB结果系统启动失败或者频繁换页。这里有个内核层面的原因shared_buffers是共享内存在启动时用shmget()或mmap映射到固定地址每个buffer管理结构BufferDesc及其associated的锁需要预分配。改大了之后内核可能需要调整SHMMAX参数。更重要的是shared_buffers不是越大越好它还涉及与操作系统页缓存的协同、检查点刷盘压力等问题需要跟checkpoint、bgwriter的参数一起权衡。我一般建议先用默认值熟悉机制再根据实际工作负载逐步调整。每一个数据页在共享缓冲区里对应一个BufferDesc结构里面记录了页的状态空闲、干净、脏、引用计数、使用计数、锁信息。后端进程读写一个页的路径是先查buffer table用page的relfilenodeblock number做hash找到对应的buffer加锁读页或写页最后释放锁并标记脏页。这套路径几乎每个查询都要走所以是内核学习的一个绝对重点。2.3 缓冲区置换当内存不够用时怎么办缓冲区不是无限大的。shared_buffers满的时候需要一个脏页换出去才能读入新页。PostgreSQL的置换算法是clock sweep时钟扫描这个机制在src/backend/storage/buffer/freelist.c里。简单说每个BufferDesc有个usage_count字段每次访问一个页时如果count小于特定上限就加1。当需要腾出缓冲区时clock指针沿buffer环形链表扫描遇到usage_count为0的干净页直接复用非0的就减1再继续扫。这样一个循环下来那些频繁访问的页因为usage_count保持在较高水平不容易被换出。这本质上是一种近似LRU算法延迟更新让高频页能“幸存”。我在实验环境里验证过一次对一张1亿行的大表做全表扫描时把每页的usage_count打出来看发现顺序扫描的页是“用完即弃”的——因为全表扫描只要一次访问clock sweep很快就把它们换出去了。而一个小表被反复join时那些页的usage_count会慢慢涨上去留在缓冲池里。这个实验让我理解了为什么同样是表有的页页能“住在内存里”有的页来来走走——这是算法设计的必然结果不是玄学。3. 事务、MVCC与WAL数据库内核的灵魂三件套3.1 事务ID、CLOG与快照原来事务状态是这样记录的PostgreSQL里每个事务都会分配一个事务IDXID它是单调递增的32位整数。但这个ID不是分配了就一直背着的——在真正修改数据之前事务可以处于“延迟分配”状态因为只读事务如果也分配XID会白白消耗事务号还导致vacuum清理受限。这是PostgreSQL一个精妙的小优化。事务状态记录在哪不是记在数据页里而是记在一个叫CLOGCommit Log的共享内存结构里落盘到pg_xact目录。CLOG按页组织每页能记录8192个事务的状态每个事务的状态用2个bit表示IN_PROGRESS、COMMITTED、ABORTED、SUBTRANSACTION。为什么这样设计因为判断一个元组是否可见最核心的问题就是“插入这个元组的事务提交了吗”。而CLOG用固定大小的bits来表示查找速度非常快。学习CLOG时可以做个小实验查看pg_current_xact_id()的值然后执行一条查询观察CLOG页的变化。我做过一个实验用一个长事务把一个表的数据改了但不提交然后去检查pg_xact_status()函数能看到这个事务ID的状态从IN_PROGRESS变成COMMITTED或ABORTED。这个直观实验让我彻底明白了事务可见性判断的根基。3.2 元组可见性规则MVCC到底是怎么做到的MVCC多版本并发控制是PostgreSQL最核心的设计之一。它不像很多数据库那样用回滚段来提供旧版本数据而是直接在堆表里保留多个版本每个版本的元组头里记录插入它的xmin、删除它的xmax。判断一个元组是否对当前事务可见核心逻辑在HeapTupleSatisfiesMVCC这个函数里。这是一段绕不过去的关键代码也是面试高频题。简化一下规则大致是如果元组的xmin是当前事务自己且xmax无效则可见如果xmin对应的事务已提交且xmax无效或对应的事务未提交则可分情况判断如果xmax对应的事务已提交说明元组已被删除不可见如果xmin对应的事务还在进行中则不可见。这套规则解决的并发场景是读不阻塞写、写不阻塞读。这也是为什么PostgreSQL能支持极高的并发读写的根基。但代价是死元组dead tuple需要automated vacuum来清理。如果vacuum跟不上表会膨胀索引会低效这是一套机制的两个侧面。我学习这个规则时用了一个特别土的办法写一个C扩展直接打印元组的t_xmin和t_xmax字段然后在不同隔离级别下执行不同的并发事务组合观察这些字段的变化。虽然PostgreSQL有现成的pageinspect扩展可以看页面的原始数据但自己动手打印更能加深理解。3.3 WAL机制崩溃后凭什么还能恢复数据数据一致性不能只靠“刷盘”解决。PostgreSQL的做法是WALWrite-Ahead Logging数据页的修改需要先记录日志日志落盘后才能把脏页刷出去。这样即使数据库崩溃也能通过重放WAL日志恢复到崩溃前的状态。WAL的核心内容在src/backend/access/transam/xlog.c里。每次事务提交walwriter要把WAL Buffer里缓存到该事务结束点的日志刷到磁盘的pg_wal目录。一个常见误解是“WAL每次提交都fsync性能肯定很差”。确实每次事务提交都要fsync这是保证持久化的底线但内核都做了很多优化group commit把多个并发事务的提交一起fsync、wal_buffers预处理、检查点削峰等。我在实验室里用pgbench压测时对比过fsyncon和fsyncoff的性能差异。off时TPS能高出一个数量级但这只适合非核心场景。这个对比实验很有价值能让你直观感受“持久性是有性能代价的”这句话的分量。需要深入理解的还包括LSNLog Sequence Number机制。每个数据页头部会记录最后一次修改它的WAL记录的LSN恢复时如果日志记录的LSN小于页面上记录的LSN说明这个修改已经刷盘了对应日志可以跳过。这就避免了崩溃恢复时重复应用日志。这套设计思路在很多存储系统里都能看到学透了可以延伸到其他分布式数据库的复制、恢复机制。4. 查询引擎从语法树到执行计划4.1 解析与语法分析SQL是怎么变成“计算机能懂”的结构的SQL文本进入内核后的第一站是解析器。PostgreSQL用flex和bison生成词法分析器和语法分析器对应文件在src/backend/parser/下词法在scan.l语法在gram.y。bison的语法规则文件非常大有两三万个规则支持了丰富的SQL语法。语法分析完成后生成Parse Tree解析树里面的节点类型是SelectStmt、InsertStmt这类结构体它们定义在src/include/nodes/parsenodes.h里。这棵树虽然已经结构化了但还不能直接执行因为里面还带着表名、列名这些符号而不是对象OID也没做权限和语义检查。接着是分析Analyze和重写Rewrite阶段。分析阶段会把表名解析成Relation OID把列名解析成属性编号把函数的字符串名称解析成函数OID同时做类型检查。重写阶段则负责视图展开、规则系统处理。如果你创建过一个视图这个阶段会把视图的定义SQL替换到查询树里形成一棵“真实”的查询树。如果在这一步出错你会看到“relation ... does not exist”或“column ... does not exist”的报错。这个阶段出错的查询根本不会进入优化器。理解这一点对排查“为什么我的SQL报对象不存在而同事的不报”之类的问题很有帮助。4.2 查询优化与执行代价模型是怎么一步步选出计划的优化器是很多人觉得最难啃的部分。它的核心思路是根据系统表里的统计信息pg_statistic由ANALYZE收集估算每个执行计划节点的行数和代价然后枚举可能的连接顺序、访问路径、连接算法选择总代价最小的计划。PostgreSQL的优化器分两个层次planner生成总体计划和subquery等模块进一步处理子查询。连接算法主要有三种嵌套循环连接、哈希连接、归并连接。分别适用不同场景小表连接小表、等值连接的大表对大表、排序数据的有序连接。优化器不是死板地挑一种而是对每个连接对都生成可能的路径按代价公式比较。执行器拿到Plan Tree后从顶层节点开始递归执行。每种节点对应一个执行函数SeqScan节点调用nodeSeqscan.c的ExecSeqScanHashJoin节点调用nodeHashjoin.c的ExecHashJoin。每个节点执行时都遵循标准的open/next/close流程用元组TupleTableSlot在节点间传递。这种Volcano式模型的特点是每执行一次next就产生一行结果内存占用小但函数调用开销高。我在做性能分析时经常用EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)来看每个节点的实际返回行数、耗时和缓冲命中情况。有一次一条两表join查询跑得很慢EXPLAIN显示优化器估算的行数比实际少了两个数量级原因是没有及时ANALYZE统计信息严重过期。这个案例能帮你理解为什么内核里统计信息模块举足轻重也说明优化器不是你写错查询的“背锅对象”很多慢查询根源在统计信息太旧。4.3 索引访问方法为什么主键查询那么快索引模块是内核里另一个学习重点。PostgreSQL的索引通过访问方法Access Method抽象接口来插拔最常用的是B-tree索引在src/backend/access/nbtree/目录下。别的还有Hash索引、GIN索引全文检索和数组、GiST索引空间和通用树等。B-tree索引用的是经典B树结构内节点只存放键值用于路由叶子节点存放实际键值和对应元组的TID块号偏移。在B-tree里面查找一个键从根节点二分向下经过三五层就能定位到叶子页再在页内二分。对于一个有几百万行的表主键等值查询往往只需四五次页面读取这是它快的关键。学习B-tree索引时有个容易忽略但很重要的部分是“索引的并发控制”。PostgreSQL的B-tree并发控制不是简单的加锁整棵树而是使用了类似“读写锁分离且向下搜索时允许短暂不一致”的算法下行搜索时加低级别锁找到合适位置后再升级到更严格的锁来插入或删除键值。这里面还涉及页分裂时的兄弟页链接和并发搜索的协调。以前我总以为B-tree就是背个B树的定义就行了其实内核里的并发细节比教科书复杂得多。用pageinspect扩展查看索引页内容是个不错的实验先建一张有主键的表插入一些数据然后用pageinspect查看索引页的元组和键值布局。我做过一次后对B树“键值物理有序”的理解立刻从抽象变成了具体。5. 实操学习法环境搭建、源码调试与验证实验5.1 本地环境搭建最快能在代码里跑通SQL的环境我自己的学习环境配置比较轻量在普通开发机上直接下载PostgreSQL源码包configure时加--enable-debug --enable-cassert --prefix$HOME/pgsql然后make、make install。--enable-debug保留调试符号--enable-cassert开启大量断言检查能在开发调试时提早暴露问题。配置完成后初始化一个数据目录启动一个临时实例cd ~/pgsql/bin ./initdb -D ~/pgdata ./pg_ctl -D ~/pgdata -l /tmp/pg.log start createdb testdb psql testdb这套环境的好处是随时可以用gdb附加到后端进程上进行调试。注意不要在生产环境的数据库上做这些实验用独立的本地实例练习出了问题直接重新initdb即可。如果想深入调试推荐用gdb 一个专门的调试脚本。PostgreSQL源码里有个src/tools/gdb目录提供了打印节点结构、元组信息的辅助函数。我经常在gdb里打断点后执行attach到一个后端进程然后运行一条SQL看它怎么一步步进入ExecSeqScan、heap_getnext这些函数。5.2 源码阅读顺序与工具三个月能读到哪里如果有人问我源码阅读顺序我会给出这样一个参考路径这是我流了很多弯路后整理出来的进程与内存先入门src/backend/main/main.c、src/backend/access/transam/xlog.c只读入口和关键路径、src/backend/storage/buffer/bufmgr.c事务与MVCCsrc/backend/access/transam/README、src/backend/access/heap/heapam.c可见性判断、src/backend/access/transam/clog.c查询引擎先读src/backend/parser/gram.y的语法结构简版再读src/backend/optimizer/plan/planner.c、src/backend/executor/execMain.c存储管理与索引src/backend/storage/page/README、src/backend/access/nbtree/README。读的时候建议配合Git历史。PostgreSQL是活跃社区每个提交都链接着社区邮件列表的讨论很多设计背后的取舍都在邮件列表里讲得很透。用git log --oneline -- 文件名看某个文件的历史能发现很多“为什么这么做”的答案。工具方面除了gdb我还会用cscope、rgripgrep做代码搜索用CLion或VSCode加上插件做代码跳转。个人体验是CLion的索引处理大型C项目更顺手但VSCode轻量免费对大多数人也够用。关键不是工具多好而是你要习惯带着“这个函数被谁调用、这个字段表示什么含义”的问题去读而不是逐行读。5.3 用实验验证机制一个小技巧抵得上十篇文档遇到晦涩的机制直接看代码容易绕晕我的办法是写一个小Demo或SQL去触发它然后打断点看执行路径。举两个我经常做的实验实验一验证MVCC的可见性函数流程。开两个psql会话一个会话更新一行但不提交另一个会话查询同一行。然后在HeapTupleSatisfiesMVCC函数下断点观察它读取的事务状态是IN_PROGRESS还是COMMITTED。你会发现当使用默认的读已提交隔离级别时每个语句都会获取新快照所以能看到已提交的新版本而在可重复读隔离级别下同一事务的所有语句共用快照所以看不到新提交的版本。这个实验极大加深了对快照和隔离级别的理解。实验二验证缓冲区置换。把shared_buffers设成很小的值比如64MB然后用一个脚本反复查询一张大表观察Buffer Pool的命中率和clock scan的移动情况。配合pg_buffercache扩展能看到哪些页被缓存在哪里、引用计数是多少。这个实验能直观地了解shared_buffers不足时的换页风暴现象。这些实验都不复杂但做一次比自己空想十遍强。内核学习最大的误区是只看不练。6. 典型问题与避坑指南6.1 复现崩溃场景用core dump定位问题学内核不可避免会碰到“自己改的代码把数据库搞崩了”的情况。第一次遇到时很可能连错误都看不懂。我的建议是先把core dump配置好ulimit -c unlimited echo /tmp/core_%e_%p /proc/sys/kernel/core_pattern崩溃后gdb解析coregdb ~/pgsql/bin/postgres /tmp/core_postgres_12345 bt常见原因无非几种指针没判空、内存上下文释放顺序错了、缓冲页锁没释放。PostgreSQL内核里大量使用palloc内存上下文一个常见错误是pg_free了不属于当前上下文的指针或者context脱离后还去访问对象。这类问题用valgrind或者开启--enable-cassert的assertion往往能在早期暴露。6.2 改了源码后重新编译的注意事项PostgreSQL的编译系统是基于Make的如果只改一个文件理论上只需要重编相关目标文件但实际使用中经常出现“改了头文件但目标文件没重新编译”导致行为诡异的问题。稳妥做法是make clean make -j8重新编译。代价是耗时但比排查诡异问题省时间。另外修改源码前先确保环境隔离。最怕的情况是你改了源码但启动的二进制还是旧的系统安装版因为PATH里面先找到的是系统目录里的PostgreSQL。检查方式是which postgres、psql --version确保指向的是自己编译目录的二进制。我踩过这个坑后每次编译安装完都会立刻执行~\/pgsql/bin/postgres --version确认。6.3 几个容易踩进去的学习误区误区一试图一次性读完源码。内核代码量大几十万行起步没有人能“读完”。正确做法是“按场景精读”比如要回答“vacuum如何清理死元组”只读vacuumlazy.c和heapam.c的相关路径即可不要为了读完而读。误区二跳过GLgeneral概念直接上代码。如果没有操作系统、编译原理、数据结构基础建议先补充一下不知道什么是页缓冲、什么是B树、什么是LRU读源码会寸步难行。建议先看一本系统级的数据库教材再回到源码。误区三不写实验只看博客。读再多别人的分析文章都不如自己跑通一次实验。我有一次为了搞清楚LockAcquire和LockRelease的逻辑写了一个模拟并发事务的小脚本反复制造锁等待场景用pg_locks视图观察锁状态变化。这个过程很慢但三个月后我对锁机制的印象依然清晰。误区四忽略代码注释里的历史原因。源码注释里经常会写“This is ugly, but ...”“Unfortunately ...”这种话。这些地方往往就是设计妥协的现场对理解“为什么是现在这样”特别有帮助。我从来不会跳过这些注释反而会专门搜索这类关键词。7. 一些个人体会学习PostgreSQL内核不是一蹴而就的事更像是一条需要持续投入的工艺线。从第一个gdb断点打在main.c上到第一次能独立分析一个查询的性能瓶颈中间可能要经历几个月甚至更长的时间。这个过程里最重要的不是记忆某个函数的细节而是逐步建立起对数据库系统的直觉一条查询在启动到返回之间要做哪些事哪些环节是性能瓶颈哪些机制在幕后保障一致性哪些配置参数影响哪条路径。如果只能给一条建议我会建议每一个想学内核的人尽早动手写实验哪怕实验本身很小。“在源码里打断点亲自走一遍执行路径”和“看别人分析文章”是两个层次的理解。前者会让你真正成为内核的“使用者之内的理解者”后者只能让你停留在“旁观者”的层面。另外PostgreSQL社区是一个非常开放的集体。邮件列表的讨论涵盖了从新手提问到资深开发者设计回顾的全部话题。遇到问题时先搜邮件列表再搜Stack Overflow最后看源码。这个顺序能节省大量时间。内核学习的终点不是“把所有模块读完”而是“遇到新问题时知道去哪里找答案并能通过源码定位到具体实现”。具备这种能力后不管是做数据库运维、内核开发还是调优都会比只会用外部文档的同行有更深一层的判断力。这条路上没有捷径但每一步都不会白走。