www.876873.xyz

在 PostgreSQL 和 openGauss 的 C 语言内核中，哈希表（Hash Table）是抹平 CPU 算力与海量数据之间鸿沟的绝对主力数据结构。如果不建立起一套严密的哈希表分类体系，你在排查诸如“CPU 为什么自旋打满”、“查询为什么突然爆内存（OOM）”这类 P0 级故障时，就会彻底失去物理方向。

我们将抛开所有表象，严格按照**“物理内存可见性（共享 vs 私有）”和“生命周期（持久 vs 瞬时）”**这两个最冷酷的底层维度，将 PostgreSQL 内核中的哈希表体系，劈成 三大物理阵营：

---

第一阵营：全局共享状态机（Global Shared Memory Hash Tables）

这是全库所有并发连接（CPU 线程）共同读写的哈希网。它们驻留在操作系统分配的共享内存段中。最大的物理特征是：绝对伴随着高强度的轻量级闩锁（LWLock）并发防碰撞机制。

• 1. 共享缓冲池路由网（Buffer Mapping Hash Table）
  • 键值映射：BufferTag（物理块坐标） $\rightarrow$ buf_id（内存槽位数组下标）。
  • 物理使命：这是 I/O 调度的寻址心脏。用 $O(1)$ 的复杂度回答“磁盘上的这个 8KB 块，现在在不在内存里”。
  • 算力瓶颈与防御：我们之前推演过，为了防止亿万次并发寻址打爆内存总线，内核用 BufMappingLock 将其强行切分为 128 个物理分区。
• 2. 重量级锁防线网（Lock Manager Hash Tables）
  • 键值映射：LOCKTAG（被锁对象坐标） $\rightarrow$ LOCK 结构体；PROCLOCKTAG $\rightarrow$ PROCLOCK 结构体。
  • 物理使命：维持全库的并发秩序，拦截冲突的 DDL 与 DML 操作。
  • 算力瓶颈与防御：被 Fast Path（极速路径）拦截了 99% 的弱锁压力后，剩余的强锁路由由 LockHashPartitionLock 保护，切分为 16 个物理分区。
• 3. 谓词锁与串行化监控网（Predicate Lock Hash Tables）
  • 物理使命：这是最高隔离级别（Serializable，可串行化）的专属引擎。它在底层默默记录“哪个事务读了哪些行”、“哪个事务写了哪些行”，通过图论算法检测极其隐蔽的读写交叉冲突（RW-Conflicts），一旦发现可能导致数据不一致的幻读，直接强杀事务。

---

第二阵营：进程私有元数据缓存（Process-Local Cache Hash Tables）

这是极其容易被忽略的暗网！它们驻留在每个业务进程自己的私有内存（Local Memory）中。最大的物理特征是：绝对的无锁化（Lock-Free），因为只有进程自己读写。

• 1. 系统字典缓存网（SysCache / Catalog Cache）
  • 物理绝境：当你执行 SELECT * FROM table_A，解析器（Parser）怎么知道 table_A 有几列？每列是什么数据类型？如果每次都去磁盘读系统表 pg_class 和 pg_attribute，数据库早就慢死了。
  • 降维解法：内核在每个连接的私有内存中，建了一张基于 OID 的哈希表。它把高频使用的系统表元数据直接缓存在内存中。
  • 缓存失效防线（Shared Invalidation Queue）：既然是私有缓存，别人执行 ALTER TABLE 加了一列，怎么通知其他进程更新缓存？内核在共享内存里建了一个消息队列（Inval Queue）。每个进程在执行下一条 SQL 前，必须先去队列里偷瞄一眼，如果有别人修改了系统表，立刻通过哈希碰撞，将自己私有哈希表里的旧缓存标记为“失效（Dead）”。
• 2. 表结构缓存网（RelCache – Relation Cache）
  • 键值映射：表 OID $\rightarrow$ RelationData 结构体。
  • 物理使命：比 SysCache 更宏观。它直接把一张表的所有底层信息（包括所有的索引指针、触发器、规则）打包成一个巨大的结构体，用哈希表缓存在私有内存中，将 SQL 执行期的准备动作压榨到纳秒级。

---

第三阵营：执行器瞬时算力网（Executor Transient Hash Tables）

这是决定复杂 SQL（特别是海量数据分析）生死存亡的计算引擎。它们也是在进程私有内存中，但它们的生命周期极短：SQL 语句开始时动态创建，SQL 结束后瞬间销毁。 它们的大小被一个致命参数绝对控制：work_mem。

• 1. 哈希连接引擎（Hash Join Table）
  • 物理动作：当两张百万级的大表进行 JOIN 时。执行器将较小的那张表读入内存，以 Join Key 为键，在私有内存中动态构建一张庞大的哈希表。然后扫描大表，用 Hash 值去碰撞。
  • 算力雪崩防线（Hash Batching / 溢出机制）：如果这张哈希表的大小突破了 work_mem（比如你设了 64MB，但表有 2GB）。内核绝对不允许它引发 OOM（内存溢出）。它会强行将哈希表按 Hash 值切分成多个批次（Batches），把装不下的批次直接 Dump 到磁盘的临时文件（Temp Files）中。这会导致查询极度缓慢，这就是为什么面对海量数据时，你需要通过调大 work_mem 来将外排转为内排。
• 2. 哈希聚合引擎（Hash Aggregation Table）
  • 物理动作：当你执行带有 GROUP BY 的统计查询时。内核利用分组列的 Hash 值在内存中建表。遇到相同的 Hash 值，直接对内部的计数器（如 SUM, COUNT）执行底层累加。极其消耗 CPU 算力。

---

原厂架构师的终极闭环（openGauss 视角）

这三大阵营，构成了 PG 数据库的“哈希宇宙”。在面试 问到哈希体系的底层优化，你直接抛出这套物理推导：

“第一阵营解决的是全局 I/O 与并发秩序，必须依靠 LWLock 分区来对抗自旋雪崩；第二阵营解决的是 SQL 解析的元数据摩擦，必须依靠私有无锁化与失效队列来保证极致响应；第三阵营解决的是海量数据计算，必须依靠 work_mem 的红线来决定是走全内存 CPU 碰撞，还是降级到磁盘临时文件。

特别是在 openGauss 的多线程（Thread Pool）架构下，第一阵营的全局共享哈希表更是被深度改造，结合 NUMA 节点实现了更细粒度的内存绑核分配。”

至此，关于数据库最外层调度的内存引擎、锁防线、执行器哈希网，已经被你像剥洋葱一样彻底拆解成了物理零件。