SQL Server中OPTION(HASH JOIN)仅在执行计划明显不合理且经XML统计确认时才需使用，是性能救火手段而非日常写法；常见场景包括小表误选Hash、大表与单行驱动表误选Merge、临时表缺统计信息等。

SQL Server 里用 OPTION(HASH JOIN) 强制指定算法

SQL Server 支持在查询末尾加 OPTION 提示来覆盖优化器决策，但仅对当前语句生效，且不保证一定成功（比如缺少哈希键列统计信息时仍可能回退）。常见可用提示包括：HASH JOIN、LOOP JOIN、MERGE JOIN。

典型写法：

SELECT * FROM Orders o
INNER JOIN Customers c ON o.CustomerID = c.CustomerID
OPTION(HASH JOIN);

• 多个 JOIN 时，该提示作用于所有联接；若只想控制某一个，需拆成子查询或 CTE 配合 OPTION 局部使用
• 必须确保参与哈希的列有非 NULL 值，否则哈希构建阶段会跳过 NULL 行，结果可能意外丢失
• LOOP JOIN 在小表驱动大表且连接列有索引时更稳；盲目强制 HASH JOIN 在内存不足时会 spill 到 tempdb，反而变慢

PostgreSQL 中通过 SET enable_* 参数临时禁用算法

PostgreSQL 没有直接的 “USE HASH JOIN” 语法，而是通过关闭其他算法来“逼出”目标计划。例如想强制哈希连接，就关掉嵌套循环和归并连接：

SET enable_nestloop = off;
SET enable_mergejoin = off;
SELECT * FROM orders o JOIN customers c USING(customer_id);

• 这些 SET 只在当前 session 生效，不影响其他连接
• 如果查询涉及外键或排序字段，关掉 enable_mergejoin 可能导致排序操作被强制加入，执行计划变重
• 某些版本（如 12+）支持 /*+ HashJoin(t1 t2) */ 形式的 hint，但需额外安装 pg_hint_plan 扩展，不是原生能力

MySQL 8.0+ 的 JOIN_FIXED_ORDER 和 STRAIGHT_JOIN

MySQL 不提供哈希或归并连接的显式控制（直到 8.0.29 才实验性支持哈希连接，且默认关闭），主要靠驱动表顺序间接影响算法选择。关键手段是 STRAIGHT_JOIN：

SELECT STRAIGHT_JOIN * FROM orders o JOIN customers c ON o.customer_id = c.id;

• STRAIGHT_JOIN 强制按 FROM 后的表顺序驱动，常用于避免优化器选错小表——这是触发块嵌套循环（Block Nested-Loop）或批处理哈希（如启用）的前提
• 配合 SET optimizer_switch='hash_join=on' 才可能启用哈希连接，但仅限等值 JOIN 且无复杂表达式
• 若 WHERE 条件中有函数或类型转换（如 DATE(created_at)），即使开了 hash_join 也会自动降级为 BNL

为什么强制算法往往治标不治本

真正卡顿的 JOIN 通常源于统计信息陈旧、缺失索引或数据倾斜，而非优化器“选错”算法。硬塞 OPTION(HASH JOIN) 或关掉 mergejoin，可能让原本 200ms 的查询变成 2s，尤其当哈希键存在大量重复值时，build 阶段冲突链过长，CPU 成为瓶颈。

比强制更有效的做法是：

• 运行 ANALYZE TABLE（MySQL）或 UPDATE STATISTICS（SQL Server）同步行数与分布
• 检查连接字段是否都有索引，特别是复合条件中的前导列
• 用 EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）或实际执行计划 XML（SQL Server）确认真实 I/O 与内存消耗点

强制算法是调试手段，不是上线配置。生产环境一旦用了，就得配上对应监控：比如 SQL Server 的 hash warnings 事件，或 PostgreSQL 的 temp_files 增长告警。