Hash Join是数据量相差一万倍时的首选算法，但需确保小表作为build side、内存充足且连接字段有索引；否则可能退化为Nested Loops，此时大表索引和ON条件写法尤为关键。
当两张表数据量相差一万倍（比如 100 行 vs 100 万行），数据库优化器通常会选 Hash Join，但“最稳妥”不等于“默认就对”——它依赖你是否控制住了 build table 的选择、内存是否够用、以及连接字段有没有索引。
为什么 Hash Join 是首选，但不是自动生效
Hash Join 的核心是把小表（build side）构建成哈希表，再用大表（probe side）逐行探测。100 行建哈希表几乎无开销，100 万次探测也远快于嵌套循环的 100 × 100 万次比较。
-
Hash Join在 SQL Server、PostgreSQL、Oracle 中默认倾向启用；MySQL 8.0+ 也支持，但需开启optimizer_switch='hash_join=on' - 如果小表实际没被选为 build side（比如优化器误判行数），可能退化成
Nested Loops，尤其当小表加了 WHERE 后只剩几行，但统计信息过期时仍按原大小估算 - 执行计划里看到
PhysicalOp="Hash Match"才算真正用了，光看语句写法没用
如何确保小表真被用作 build table
build table 不由 LEFT/RIGHT 语法决定，而由优化器基于预估行数和索引可用性判断。你得主动干预：
- 强制更新统计信息：
UPDATE STATISTICS small_table WITH FULLSCAN，避免优化器以为小表有 10 万行 - 用查询提示（SQL Server）：
SELECT /*+ HASH JOIN(small_table) */ ...或OPTION (HASH JOIN)，但仅当确认小表确实小且稳定 - 避免在小表上写会导致估算失真的条件，比如
WHERE date_col > GETDATE() - 1（函数使统计失效），改用变量或参数化
当 Hash Join 失效时，Nested Loops 可能更稳
不是所有场景都适合 Hash Join：内存不足、小表实际带大量重复值（哈希冲突高）、或连接字段无索引时，Nested Loops 反而更可控。
- 如果大表连接字段有索引（比如
orders.user_id上有 B+ 树索引），Nested Loops用小表每行去索引查大表，复杂度是O(M × logN)，比全表扫描靠谱得多 - 检查
EXPLAIN或执行计划中内表的type是否为ref或eq_ref；若是ALL，说明索引没走，Nested Loops就真成灾难 - SQL Server 中出现
Warning: Hash warning: No join predicate，说明ON条件漏写，直接退化成笛卡尔积——这时哪怕表再小，结果集也会爆炸
LEFT JOIN 场景下驱动表不可控，得靠 ON 条件收口
LEFT JOIN 的左表固定为驱动表，但右表若没索引或过滤条件写在 WHERE 里，优化器可能放弃 Hash Join，转而用低效路径。
- 右表的过滤必须写进
ON子句，而不是WHERE：比如LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'，否则WHERE o.status = 'paid'会让 NULL 行被剔除，语义变味，还可能误导优化器 - 如果右表字段类型和左表不一致（如
VARCHARvsINT），隐式转换会让索引失效，Nested Loops就只能全表扫——这种细节比算法选择更容易让查询崩掉 - 千万注意：
LEFT JOIN下，即使右表只有 100 行，只要ON条件没索引，它仍可能被当作 100 万行处理
数据量差一万倍时，算法本身不是瓶颈，真正卡住的是统计信息准确性、索引覆盖完整性、以及 ON 条件是否干净。别急着调优 JOIN 类型，先跑一遍 EXPLAIN 看实际走哪条路，再盯住 build/probe 两侧的预估行数和实际行数是否接近——差十倍以上，更新统计信息比重写 SQL 更有效。
