hash join落盘主因是内存不足导致哈希表整桶刷磁盘，性能骤降10⁵倍；需先验证disk usage是否非零、排除数据倾斜与类型不一致等根因，再按数据库特性调优work_mem/spilllevel等参数。
Hash Join 落盘不是“慢一点”，是 IO 爆炸
Hash Join 变慢的主因不是算法本身低效，而是 work_mem（PostgreSQL）、hash_join_seed（MySQL）或 tempdb 空间（SQL Server）不足导致哈希表整桶刷磁盘。一次内存中的哈希探查本该是纳秒级指针跳转，落到磁盘后变成毫秒级随机寻道——性能被拉低 10⁵ 倍以上。
典型信号包括：EXPLAIN (ANALYZE, BUFFERS) 中出现非零 Disk Usage、执行时间里 Temp Read/Temp Write 占比超 70%、Shared Hit 骤降而 Local Hit 暴增。日志里若出现 writing to disk due to insufficient memory，就是明确落盘证据。
- PostgreSQL 不会只写“一部分”哈希表：它按桶切片，内存不够就整批刷到
pg_temp_*临时文件，后续每次 probe 都要反复读磁盘 - 临时文件不走
shared_buffers缓存，OS page cache 也难命中（访问模式高度随机） - SQL Server 的溢出表现为
ERROR 701或Could not allocate space for object 'dbo.#hash_table' in database 'tempdb'
先确认真瓶颈，别一上来就调内存
Hash Join 慢，90% 的情况不是内存小，而是底层问题被暴露出来：数据倾斜、统计信息过期、JOIN 字段类型不一致。盲目加大 work_mem 或关掉 hash_join，只是掩盖症状。
必须按顺序验证：
- 跑
EXPLAIN (ANALYZE, BUFFERS)，看 Hash 节点的Disk Usage是否为 0；若为 0，说明根本没落盘，work_mem不是瓶颈 - 查
pg_stat_progress_hash（PG v12+），看hash_probe_total_buckets / hash_buckets_used比值：若远大于 3，说明桶太稀疏，才是内存不足 - 快速验数据倾斜：
SELECT key, COUNT(*) FROM table GROUP BY key ORDER BY 2 DESC LIMIT 5；若 TOP1 频次 > 平均值 × 10，加内存基本白费 - 检查 JOIN 字段类型是否一致（比如
CAST(u.id AS TEXT) = o.user_id），类型强转会导致索引失效 + 构建表规模失控
work_mem / hash_join_seed / tempdb —— 各数据库调优关键点
不同数据库对 Hash Join 的资源控制机制差异极大，不能套用同一套参数逻辑。
- PostgreSQL：
work_mem是“每个操作节点”独享上限，一个含 2 个 Hash Join + 1 个 Sort 的查询可能吃掉 3×work_mem；建议从'32MB'起步，用SET LOCAL work_mem = '64MB'仅限当前事务生效；全局改极易引发 OOM - MySQL：
hash_join_seed是诊断开关，不是调优参数；临时禁用用SET SESSION optimizer_switch='hash_join=off'；注意它不能在事务中动态修改后立即生效，需在BEGIN前设置 - SQL Server：重点看执行计划中 Hash Match 节点的
SpillLevel > 0或Operator used tempdb；查sys.dm_db_session_space_usage中internal_objects_alloc_page_count是否飙升
真正要动的不是 Hash Join，是驱动表和索引
Hash Join 是结果，不是原因。它暴露的是驱动表过大、被驱动表缺索引、WHERE 条件未下推等硬伤。
- 驱动表应尽可能小：把高过滤度条件（如
status = 'paid'）放在 JOIN 前，而不是塞进 ON 子句 - 被驱动表连接字段必须有索引：比如
orders JOIN users ON orders.user_id = users.id，users.id必须是主键或唯一索引，否则哈希探测退化为全表扫描 - 避免 ON 里函数转换：
UPPER(a.id) = UPPER(b.id)会让索引失效，优化器只能硬上 Hash，且无法缩小输入规模 - SQL Server 的 UPDATE 场景默认倾向 Hash Join，但更稳的解法是给左表建
(WHERE 列, JOIN 列)复合索引，右表建窄索引如CREATE INDEX IX_t2_tid ON t2(t1_id)
最容易被忽略的点：连接字段类型不一致（如 bigint vs text）会触发整表隐式转换，索引彻底失效——这时哪怕调高内存，也救不回 Seq Scan。
