外连接落盘主因是底层Hash Join或Sort操作的work_mem不足，需通过EXPLAIN (ANALYZE, BUFFERS)定位Disk Usage非零的Hash节点或“Sort Method: external merge”节点，再按驱动表规模与操作路数叠加估算内存并用SET LOCAL针对性调优。

外连接（LEFT/RIGHT JOIN）在PostgreSQL 14中落盘，大概率不是JOIN类型本身的问题，而是底层用了Hash Join或Sort操作且work_mem不足——先确认执行计划里哪个节点写磁盘，再针对性调。

怎么一眼看出是Hash Join还是Sort导致外连接落盘

外连接不等于一定走Hash Join：PostgreSQL会根据统计信息和成本估算选执行路径。但一旦看到落盘，90%是Hash Join或后续ORDER BY/SUM OVER等配套操作触发的。

• 运行EXPLAIN (ANALYZE, BUFFERS)，重点找带Disk Usage非零的Hash节点，或Sort Method: external merge Disk的Sort节点
• 如果Hash节点没写磁盘，但WindowAgg或GroupAggregate节点有external字样，说明外连接结果集被后续操作“二次加工”时落盘了
• 注意Temp Read/Temp Write总量：超过100MB基本可断定是内存瓶颈，不是数据倾斜

外连接场景下work_mem该设多大才够用

不能只看表大小，得按“驱动表+操作路数”算。比如LEFT JOIN orders ON users.id = orders.user_id，若users是小表（驱动表），orders是大表（被探测表），哈希表主要由users构建。

• 粗略估算：假设users有5万行，id是BIGINT（8字节），加上指针和填充因子，需内存 ≈ 50000 × (8 + 8) × 1.5 ≈ 1.2MB —— 这就是单次Hash操作的保底值
• 但一个外连接查询常伴随ORDER BY、LIMIT、GROUP BY，可能同时启动2–3个独立排序/哈希操作，总内存消耗是叠加的
• 起始建议：SET LOCAL work_mem = '16MB'；若仍落盘，试'32MB' → '64MB'；超过'128MB'前，务必确认并发查询数是否可控

为什么SET LOCAL work_mem在外连接里特别重要

全局改work_mem对OLTP事务是灾难：一个简单INSERT也可能触发隐式排序（比如带ON CONFLICT ... ORDER BY），无差别吃掉高配额内存。

• 外连接多出现在报表或ETL场景，生命周期明确，适合在事务开头显式设置：BEGIN; SET LOCAL work_mem = '64MB'; SELECT * FROM users LEFT JOIN orders ... ; COMMIT;
• 若用PgBouncer，检查ignore_startup_parameters是否包含work_mem，否则SET LOCAL会被静默忽略
• 函数体内慎用SET LOCAL：它会影响整个函数调用栈，可能污染上游事务的内存预算

真正容易被忽略的是：外连接本身不直接消耗work_mem，它只是“触发器”。实际落盘的往往是后续的排序、去重、窗口计算——盯紧执行计划里第一个external出现的位置，那里才是该加内存的地方。