深入解析 Hash Join 原理

⚡ 核心优势

1. 无需索引：不依赖连接列上的索引，适合全表扫描场景。
2. 并行处理：哈希表构建和探测阶段都可以高度并行化。
3. 适合大表：当连接率较低（即匹配行数少）时，效率远高于Nested Loop。

⚙️ 适用场景

1. 不等值连接：如 A.id > B.id。
2. 大表连接：一个表很小，另一个表非常大。
3. 笛卡尔积过滤：当连接条件过滤掉大部分数据时。

? 局限性

1. 内存敏感：需要足够的内存来构建哈希表，否则会发生磁盘Spilling。
2. 构建开销：哈希表的构建需要额外的CPU和内存开销。
3. 小表不适用：如果两个表都很小，Nested Loop可能更快。

1. 避免 Spilling（磁盘溢出）

Spilling是Hash Join性能杀手。当哈希表太大无法放入内存时，数据库会将部分哈希表写入磁盘，导致I/O激增。

解决方案：

• 增加数据库的内存池大小（如 PostgreSQL 的 work_mem）。
• 确保统计信息准确，以便优化器选择正确的表作为Build Side。
• 减少Build Side的行数，通过WHERE子句提前过滤数据。

2. 选择正确的 Build Side

优化器通常会自动选择较小的表作为Build Side，但有时它会出错。

解决方案：

• 手动调整查询结构，强制较小的表作为驱动表。
• 检查统计信息是否过期，更新统计信息。
• 在Oracle中，可以使用HINT /+ USE_HASH(A B) LEADING(A) / 来控制。

3. 减少哈希冲突

虽然现代哈希算法冲突率很低，但在极端数据分布下仍可能发生。

解决方案：

• 确保连接列的数据类型一致，避免隐式类型转换导致无法使用哈希。
• 对于字符串连接，使用高效的哈希函数（如 MurmurHash）。

Q: Hash Join 支持哪些连接类型？

A: Hash Join支持Inner Join, Left Outer Join, Right Outer Join, 和 Full Outer Join。对于Outer Join，数据库会在Probe阶段额外记录未匹配的行，以便后续填充NULL。

Q: 为什么有时 Hash Join 比 Nested Loop 慢？

A: 如果两个表都非常小，或者连接结果集非常大（高选择性），Hash Join的哈希表构建开销可能超过Nested Loop的I/O开销。此外，如果内存不足导致Spilling，性能会急剧下降。

Q: 如何查看数据库是否使用了 Hash Join？

A: 在大多数数据库中，可以使用 EXPLAIN 或 EXPLAIN ANALYZE 命令查看执行计划。在计划中查找 “Hash Join”, “Hash”, “Hash Join” 等关键字。