SQL Server大表JOIN默认选HASH JOIN易内存溢出，因需将内表全量哈希载入内存；应优先确保JOIN字段类型一致、索引有效、统计信息准确，并通过ORDER BY或OPTION(MERGE JOIN)引导优化器选用低内存的MERGE JOIN。
SQL Server 默认对大表 JOIN 往往选择 HASH JOIN，但它会把整个内表（右表）哈希加载进内存；一旦数据量或字段宽度超出 hash_join 可用内存（受 max server memory 和查询并发挤压影响），就会触发磁盘哈希溢出——不是慢一点，而是写临时文件、卡死、甚至报 ERROR 701 (Out of memory)。这不是调大内存就能根治的问题，关键在让优化器选对算法，或主动干预。
为什么加了索引 SQL Server 还硬要用 HASH JOIN？
常见误判场景：
- JOIN 字段类型不一致，比如
INT对BIGINT或VARCHAR(50)对VARCHAR(100)，触发隐式转换，索引失效，优化器只能退回到HASH JOIN - WHERE 条件过滤性差（如
status IN ('A','B','C')占全表 80%），导致驱动表结果集过大，MERGE JOIN需要双排序成本高，优化器倾向选HASH - 统计信息过期，
SELECT COUNT(*) FROM orders WHERE user_id = 12345实际只返回 3 行，但优化器预估是 3000 行，误判为“大结果集”，放弃NESTED LOOPS - 未建覆盖索引：例如
JOIN users u ON o.user_id = u.id后还要查u.name, u.email，但users(id)是聚集索引，而name/email不在索引中，MERGE JOIN虽能走索引扫描，却要回表，优化器权衡后仍选HASH
如何用提示（hint）强制改用 MERGE JOIN？
MERGE JOIN 不吃内存，只要两表 JOIN 列都有已排序的 B-tree 索引（聚集索引或含该列的非聚集索引），它就逐行归并，内存占用恒定。但 SQL Server 不会自动选它，除非你给足信号：
- 确保两边 JOIN 列都有索引，且顺序一致（升序/升序 或 降序/降序）；例如
orders(user_id)和users(id)都是 ASC - 显式加
ORDER BY强制排序输出：即使业务不需要，加ORDER BY o.user_id会让优化器看到“已排序路径”，更倾向MERGE JOIN - 用
OPTION (MERGE JOIN)提示，但仅当执行计划确认可行时才用——如果缺索引，加提示会直接报错Query processor could not produce a query plan - 避免和
FORCE ORDER混用：后者会锁死连接顺序，可能让MERGE失效
示例：
SELECT o.order_no, u.name FROM orders o INNER JOIN users u ON o.user_id = u.id ORDER BY o.user_id OPTION (MERGE JOIN);
HASH JOIN 能不能安全用？怎么控住它的内存？
可以，但必须满足两个前提：你知道它要载入多少数据，且能保证不溢出。否则不如不用。
- 查执行计划里的
Estimated Number of Rows，乘以每行平均字节（用sp_spaceused 'users'看 avg_row_size）粗算内存需求；别信“几万行就没事”——含TEXT、XML或多个VARCHAR(2000)的行，一行就占几百 KB - 临时提高单查询可用内存：在语句前加
OPTION (QUERYTRACEON 9481)（启用旧版优化器，有时更保守）或结合SET STATISTICS XML ON观察实际内存申请峰值 - 禁用全局哈希（仅诊断）：
OPTION (HASH JOIN, LOOP JOIN)不合法，但可设DBCC TRACEON(2336,-1)关闭哈希，看是否真能切到NESTED LOOPS；生产环境严禁长期开启 - 真正可控的做法：用
TOP N+OFFSET/FETCH分批，把一次大HASH JOIN拆成多次小内存操作，比调参可靠得多
最容易被忽略的细节：tempdb 和 max server memory 的隐性冲突
很多人调大 max server memory，以为就能撑住 HASH JOIN，却忘了 SQL Server 的哈希溢出、排序、游标等都依赖 tempdb。当 tempdb 文件太小、单文件、或放在慢盘上，溢出写磁盘的速度比内存分配还慢，查询反而更卡。
- 检查
tempdb是否多文件：至少 4 个，大小均等，关闭自动增长（提前预分配） - 确认
tempdb所在磁盘 IO 延迟 -
max server memory设太高（比如 90% 物理内存），留给tempdb缓冲和 OS 的空间就少，可能触发系统级 OOM - 运行
SELECT * FROM sys.dm_db_task_space_usage查当前哪个 session 在狂写tempdb，定位是不是某个 JOIN 在偷偷溢出
