PostgreSQL哈希连接原理：从EXPLAIN读懂Batches与性能瓶颈-北京尧图网络

第一次在真实环境里看到一条 SQL 的 EXPLAIN 输出出现Batches: 8的时候我第一反应是去翻资料搞清楚这个字段到底在说什么。后来把整条执行链路摸了一遍才明白PostgreSQL 默认的 hash join 实现在数据库理论里通常被归为 hybrid hash join——它在内存够用的时候就是普通的内存哈希连接一旦数据量超过可用的内存预算就会自动把哈希表拆成多个批次把暂时用不到的批次写进临时文件再分批次读回来做匹配。整个过程看起来很像“先尽量在内存里干活实在不行就分批搬家”。这篇文章我不想从 executor 的状态机角度去讲什么 ExecInitHashJoin、ExecHashJoin 的状态流转这类内容资料里已经很充分了实际排查问题时反而不顺手。我更想用一条数据流动的路径来讲清楚 hybrid hash join 到底干了什么、什么时候会用上它、以及怎么从 EXPLAIN 里判断它是健康还是已经病得不轻。适合谁看呢主要是刚接触 PostgreSQL 性能调优的后端开发、DBA以及那些对 EXPLAIN 里的 Hash 节点一知半解、想彻底搞懂底层原理的读者。1. 先搞懂 hybrid hash join 到底“hybrid”在哪1.1 内存哈希连接的基本动作普通的 hash join 其实很简单准备两个输入一边叫 build 侧另一边叫 probe 侧。执行器先把 build 侧的每一行数据计算一个哈希值按照哈希值放进内存里的哈希表然后扫描 probe 侧的每一行同样计算哈希值去内存哈希表里查对应的桶能查到就说明键值匹配把两行合并成结果输出。这个过程可以类比成查字典build 侧就是“把一批词按拼音首字母整理好放进目录”probe 侧是“拿着要查的词去目录里精确翻页”。它的时间复杂度平均在 O(NM)也就是两边各扫一遍相比嵌套循环那种 O(N*M) 的笛卡尔式比较优势非常明显。这里的核心假设是build 侧的哈希表能完整放进内存。如果数据量小这当然没问题。但现实查询经常遇到几千万行的大表做关联哈希表占用的内存可能远超连接进程的预算这时候就必须想办法了。1.2 内存预算不够时hybrid 的切入方式hybrid hash join 的“hybrid”指的就是内存哈希连接和磁盘分批连接两种策略的混合使用。当优化器估算出 build 侧数据量过大超过了内存预算通常是 work_mem 相关参数的限制时执行器不会傻傻地一次性把所有数据都塞进内存也不会把所有数据都立刻倒到磁盘上。它会把哈希表的哈希值空间切成若干个区间每个区间称为一个 batch批次。举个例子假设需要分成 4 个批次PostgreSQL 会先在内存里构建第 0 批的哈希表另外 3 批的数据则在构建阶段直接写入临时文件。探测阶段开始后先从 probe 侧读数据如果数据属于第 0 批就在内存哈希表里直接匹配如果属于其他批次就先写到对应的临时文件里。等第 0 批处理完内存哈希表清空再加载第 1 批的数据构建哈希表然后把之前暂存的第 1 批 probe 数据拿出来匹配。这个过程依次循环直到所有批次都处理完。这样做的收益很直接任何时刻内存里只需要容纳一个批次的数据而不是整个庞大的哈希表。代价是部分数据要经历“写临时文件—读回内存”的 IO 过程但这比内存直接爆掉要可控得多。1.3 和 Grace hash join 的关系很多人第一次听到 hybrid hash join 会以为它跟 Grace hash join 是两个完全不同的算法。实际上Grace hash join 的思想是如果数据太大就先把两个输入都按同一个哈希函数分区写到磁盘上的多个文件中然后逐个分区读回内存做连接。而 hybrid hash join 是 Grace 的一个变种——它不会把第一分区也写到磁盘而是尽量把第一个分区的哈希表保留在内存里直接减少一次磁盘写入和读回的 IO 开销。PostgreSQL 的 hash join 实现从行为上说正符合 hybrid 的定义。它不是一个独立的、可以选择开关的算法而是默认 hash join 在大数据量场景下的自我升级形态。所以你在 EXPLAIN 里看到的所有 Hash Join 节点本质上都可能是 hybrid hash join只是可能因为数据量小退化为 trivially 的内存版而已。理解这一点很重要没有哪个参数叫 enable_hybrid_hash_join你也不需要显式开启它。优化器在执行前就已经根据估算决定好了 batch 数执行器按计划走流程。2. 一条元组在 hybrid hash join 里的完整旅程2.1 构建阶段进桶还是进批次Hash 节点在构建哈希表时对每一行输入数据都会走一个分流逻辑。PostgreSQL 内部会计算出一个哈希值这个值会被拆成两部分使用低比特位用来定位哈希桶bucket高比特位用来定位批次batch。当批次数为 1 时所有数据都进内存哈希表不需要分区当批次大于 1 时每条元组会根据 hash 值落入某个批次只有当前正在处理的批次数据会真正占用内存哈希表空间。这种用高低比特位分别选桶和选批次的设计不是随意决定的。如果只用哈希值对批次取模很容易导致同一哈希链上的数据被拆到不同批次增加不必要的临时文件 IO。而现在这种设计可以让哈希分布相对均匀同时保证同一个连接键的数据大概率被分到同一批次不至于出现键值明明相等、却因为批次不同而在探测阶段错过的尴尬。构建过程中如果某个批次的数据量依然大得离谱内存哈希表有膨胀风险执行器会触发批次再分裂。这一层的处理逻辑参考了“递归溢出”的思路当前批次被继续切分成更多子批次原本在内存中的部分元组也会被重新写回磁盘。因为这一层操作在运行时才会发生所以经常是性能问题的真正来源。2.2 探测阶段先查内存再落地匹配探测阶段发生在 Hash Join 节点的外层循环里。每一次从 probe 侧读取一行都会做一次同类哈希计算然后判断这条数据属于哪个批次。如果它属于当前内存里已经构建好哈希表的批次那就直接在哈希表里查找命中就输出连接结果没命中就跳过。如果它属于尚未加载的其他批次执行器不会让它白白待在内存里等而是把它追加写入该批次对应的临时文件等轮到这个批次再被加载进内存时从临时文件里顺序读出并匹配。整个过程可以用一条“批处理流水线”来理解内存里始终只有当前一个批次的建表数据probe 侧其他批次的数据都在外存“排队”。这样做能让大表关联在受限内存下依然完成只是付出的代价是多出一次磁盘读写。顺带提一个容易踩的误区很多人以为 hash join 是“把两个表都装进内存再合并”这是不对的。build 侧建哈希表probe 侧只是逐行流式检查会保存一部分临时数据到磁盘但绝对不是两个完整表都需要塞进内存。理解这一点对后面判断内存参数该调多大很重要。2.3 批次之后的二次分裂递归溢出如果预估批次正常但运行时的数据分布跟预期差异很大执行器可能遭遇“某个批次单独就超过内存预算”的情况。比如某个 join 键的取值特别集中大量数据落进了同一个批次这个批次的哈希表即使翻倍分配也不够放。遇到这种情况PostgreSQL 会执行一次 “增加批次数量” 的操作把当前的单个大批次再分成多个更小的批次。原先在内存里的部分元组会被释放或者重新定位到新的子批次中去。这个分裂动作可能发生不止一次每一次都会伴随额外的临时文件写入。从观察者的视角看这种递归溢出通常意味着统计信息与实际数据严重偏差或者 join 列的数据倾斜太严重。别急着把这个问题归结为参数不够大先想想为什么数据分布会集中——很多时候这才是解药。3. 优化器如何评估 cost 并选中 hybrid hash join3.1 哪些 join 条件能用 hash join不是所有连接都能用 hash join。PostgreSQL 的 hash join 只支持等值连接条件也就是a.id b.id这种且连接列的类型必须支持可哈希。如果查询里还有a.create_time b.create_time这类范围条件hash join 只能处理等值部分范围条件要么退化成其他连接方式要么在输出阶段用 filter 再做一次过滤。相比而言nested loop join 几乎支持任意连接条件包括非等值merge join 则要求两侧都能按连接键排序支持等值和部分不等值但实现相对复杂。所以实际规划中优化器会先看查询条件再决定候选的 join 策略集合。下面是一个粗粒度的对比表格方便建立直觉Join 方式支持条件内存需求适用场景Nested Loop任意条件极低无哈希表外表小、内表有索引、或者非等值连接Merge Join要求两侧可排序低依赖排序两侧已排序或数据量大且有序Hybrid Hash Join仅等值且可哈希较高可批次落盘无索引大表关联等值条件且内存预算有限实际执行中优化器会为每个可行的 join 路径估算 cost选择成本最低的那个。很多情况下即使有索引存在hash join 的整体成本也可能低于 nested loop join尤其是大表之间关联时。3.2 批次数量是怎么估算出来的Planner 在决定批次数量时会先估算 build 侧结果集的元组数量、平均行宽然后估算出一个完整的哈希表需要占用多少内存。这个估算会考虑元组头、哈希 key、哈希桶数组等额外开销而不只是数据本身的大小。然后拿这个估算值和内存预算做除法。内存预算的基准是 work_mem从 PostgreSQL 13 开始 hash join 还可以乘以 hash_mem_multiplier 这个系数默认是 1.0。如果估算出的内存占用小于预算批次数量就是 1走全内存路径反之批次数量会向上取整到 2 的幂比如 2、4、8、16这样位运算方便桶和批次的划分也更均匀。关键是批次数量是计划阶段的估算结果。如果统计信息准确这个估算基本可靠如果ANALYZE没跑、统计信息过期或者 join 列有严重数据倾斜估算就可能严重低估或高估。3.3 为什么 Explain 里的 Batches 可能比你预期的多有几次线上排查我看到某条查询的 EXPLAIN 输出里Batches高达几千甚至上万第一反应是 work_mem 太小。深入查下去发现根本原因是其中一张表的过滤条件选择性被严重高估——统计信息告诉优化器这个过滤条件能滤掉 99% 数据实际却只滤掉 10%于是 planner 以为 build 侧只要 1 个 batch执行时才发现内存根本装不下触发递归分裂。另一个常见原因是 join 列的数据类型比较“宽”比如用长字符串或 UUID 做连接键单条哈希表条目占用的内存比优化器按平均宽度估算的高不少。数据倾斜也可能导致个别批次膨胀触发多次分裂让实际 batch 数量和计划值产生巨大偏差。所以看到Batches: 1024这种数字时先别急着调参数。用EXPLAIN ANALYZE对比一下计划中的批次数和实际的批次数再判断是估算问题还是单纯的内存不足。3.4 和 nested loop / merge join 的分界线从成本模型的角度hash join 的构建阶段需要对 build 侧全量做哈希代价是 O(N) 级别的 CPU 和内存分配。probe 阶段则对另一侧逐行访问哈希表平均接近 O(1)。所以 hash join 对“一侧中等、另一侧很大”的场景通常非常高效。nested loop join 是真正更依赖索引的 join 方式——如果内表连接列上有索引每次外表的行都能走索引定位那么外表很小的时候它的总成本可能远低于构建一个巨大哈希表的成本。反过来如果两边都没有索引、都是几百万行nested loop 几乎必死无疑。merge join 则适合两侧数据已按连接键排序的情况比如两个子查询里正好有ORDER BY或者走了索引扫描。在这种情况下merge join 可以做到线性扫描加合并不需要额外哈希运算CPU 成本更低。但为了排序而额外付出的 sort 成本往往不低所以实际并不总是最优。这也是为什么我们不能只看“hash join 很快”就迷信它——优化器会在每个具体场景下算账我们要做的是确保它的账本上有足够准确的统计信息。4. 从 EXPLAIN 里读出 hash join 的“健康度”4.1 几个字段的真正含义EXPLAIN 输出里 Hash 节点那一行通常会显示类似下面的信息Hash Join (cost400.50..8000.30 rows100000 width24) Hash Cond: (t1.id t2.id) - Seq Scan on t1 ... - Hash Buckets: 4096 Batches: 4 Memory Usage: 65536kB Peak Memory Usage: 65536kB这里几个字段的对应关系是Buckets表示哈希桶数组的大小它决定哈希表内部的查找粒度Batches表示计划或实际使用的批次数量Memory Usage表示该哈希表当前占用的内存量注意它只是当前一个批次占用的内存不是所有批次的总和Peak Memory Usage是 EXPLAIN ANALYZE 才会出现的峰值内存占用。理解Memory Usage和总内存的关系非常重要。Batches 为 4 的时候内存里同时只有 1 个批次的哈希表所以内存占用可能看起来“不大”但这不代表所有数据都在内存里另外几个批次可能正在临时文件里睡大觉。4.2 健康与不健康的典型表现最健康的状态当然是Batches: 1说明整个哈希表都能放进内存没有临时文件 IO。这种情况下的 hash join 通常执行很快内存占用也不会太夸张。亚健康状态是Batches: 2或4只有少量批次落盘临时文件不大执行时间可能会增加一些但整体可接受。这种情况不一定需要调优尤其在数据量确实很大的前提下分批执行是正常的。比较危险的信号是Batches值非常大比如几十甚至几千且EXPLAIN ANALYZE里能看到大量临时文件读写。这时候执行时间通常是秒级跳到分钟级因为每个批次都要与磁盘交换数据。如果同时Peak Memory Usage没有接近上限很可能说明批次分裂是因为数据分布不均而不是纯粹的内存预算不足。还可以结合两个数字一起看Memory Usage远低于 work_mem但Batches却很大。这是典型的“估算偏差”特征优先修统计信息比调内存更有用。4.3 真实慢查询的一个判断过程之前帮某项目组排查过一条报表查询两张千万级表按订单号关联EXPLAIN 显示Batches: 16384执行时间在 40 秒以上数据库目录里临时文件涨到几十 GB。从表面看这像是 work_mem 设置太小导致的疯狂溢写。我先把会话的 work_mem 临时调到 1GB 重新执行发现批次数量确实下降了不少执行时间却仍然在 10 秒开外。继续查统计信息才发现订单表上的过滤字段有大量 NULL 值而优化器估算时默认这些 NULL 会被过滤掉实际结果集大小和估算差了三个数量级。等我把统计信息刷新并重新执行批次数量降到了 32执行时间降到 3 秒左右。这个案例说明EXPLAIN 里的数值不是孤立的。调参数可以掩盖一部分问题但根因在数据本身时再大的 work_mem 也救不回来。5. 调优和排障中真正值得做的事情5.1 work_mem 和 hash_mem_multiplier 的正确打开方式work_mem 是每个数据库会话里每个排序或哈希操作可用的内存上限不是实例级的总内存池。如果一个连接同时执行多个排序和哈希操作每个操作都能单独占满 work_mem总内存可能成倍上涨。这就是为什么全局把 work_mem 调很高是危险的很容易把整台机器的内存吃掉。hash_mem_multiplier 是从 PostgreSQL 13 开始加入的系数专门控制 hash join 和 hash 聚合操作相对 work_mem 的内存上限。比如设置hash_mem_multiplier 2.0且work_mem 64MB那么 hash join 最多可以用到 128MB而排序操作仍然只受 64MB 限制。这个设计让 DBA 可以单独放宽哈希类操作不至于让排序操作也跟着多吃内存。实际排查时我更推荐在会话级别临时调整而不是直接改集群配置。比如在事务里执行BEGIN; SET LOCAL work_mem 256MB; SET LOCAL hash_mem_multiplier 1.5; EXPLAIN ANALYZE SELECT ...; ROLLBACK;这样可以安全地测试不同内存参数对查询的影响不用全局改动也不会影响其他正在运行的会话。5.2 临时文件监控temp_file_limit 与 pgsql_tmphash join 溢写会被写到临时文件默认位置在数据目录的base/pgsql_tmp下。如果这类文件快速增长说明数据库正在频繁把批次数据落盘。用下面这个查询可以快速观察当前库的临时文件累计情况SELECT temp_files, temp_bytes FROM pg_stat_database WHERE datname current_database();更稳妥的做法是设置temp_file_limit给所有临时文件总量设一个硬上限。这个参数的作用是防止某个失控查询把磁盘写满从而拖垮整个实例。在生产环境中我建议根据磁盘空间规划一个合理阈值比如 10GB 或 20GB超过之后查询会直接报错退出而不是无限膨胀。注意临时文件本身不是 bug数据库在内存不足时落盘是正常行为。要紧的是判断这个落盘是计划内的批次策略还是统计偏差导致的意外溢写。前者的标识是 Batches 数量与计划一致后者则经常伴随实际批次远大于计划批次。5.3 治本思路别把所有问题都归咎于 hash join调优到最后我越来越觉得 hash join 本身很少是根因更多时候它只是“受害者”。你能做的真正有价值的事情通常集中在三个方面让统计信息更准确让连接键分布更均匀让查询结构更利于裁剪数据。统计信息方面定期ANALYZE大表或者在批量导入后手动收集统计信息能显著减少 Batches 估算偏差。数据分布方面如果 join 列倾斜严重可能需要考虑业务侧是否能先做过滤、再关联。查询结构方面提前在小结果集上完成过滤再连大表往往可以让 build 侧的哈希表显著变小。至于是否要给 join 列加索引、是否要把 hash join 强制改成 merge join那都是后话。先回到数据本身去看问题往往比连续调参数更高效。我个人处理这类问题的习惯是先看统计信息和执行计划再看临时文件和批次最后才动内存参数这个顺序救过我很多次。

PostgreSQL哈希连接原理：从EXPLAIN读懂Batches与性能瓶颈

相关推荐

避障技术十年演进：从碰撞补偿到语义感知的工程实践

基于Python的网络流量分析与入侵检测系统实战解析

MCP协议+AI Agent驱动工业仿真自动化

更多资讯

深入解析TEE可信执行环境：从TrustZone架构到OP-TEE应用开发实战

SRIM带电粒子输运建模：从命令行配置到RBS实测校准

lingbot-map：自动化映射引擎的设计与实现

AI裁判如何化解文献冲突？从证据等级到综述写作的实战指南

数据治理五域模型：标准、质量、元数据、主数据与安全的协同落地方法论

Hive表数据加载六种方式原理与实战选型指南

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？