SQL Server 2022的HASH JOIN突然吃光内存，主因是自适应连接（Adaptive Joins）在运行时将Nested Loops临时切为HASH JOIN，而其内存预估严重依赖统计信息准确性；一旦行数预估偏差超5倍（如实际10万行、预估仅2000行），即按小表建哈希表，运行时发现是大表，强行加载导致ERROR 701。常见诱因包括：JOIN字段未更新统计信息、datetime与datetime2隐式转换使直方图失效、WHERE含GETDATE()或参数化查询引发参数嗅探失准。解决方法包括：对高危语句加OPTION (USE HINT('DISABLE_BATCH_MODE_ADAPTIVE_JOINS'))禁用自适应，或显式指定OPTION (LOOP JOIN)；检查执行计划XML中1节点确认是否启用；避免LEFT JOIN宽表全字段SELECT及跨库JOIN未下推——后者需用OPENQUERY强制过滤或分步走临时表控制数据量。
SQL Server 2022的HASH JOIN为什么突然吃光内存？
不是HASH JOIN本身变坏了，而是2022默认启用自适应连接（Adaptive Joins）后，优化器可能在运行时把原计划的Nested Loops临时切到HASH JOIN——而HASH JOIN的内存预估严重依赖统计信息准确性。一旦rows预估偏差超5倍（比如实际10万行，预估2000行），它就会按小表建哈希表，结果运行时发现是大表，只能硬扛着往内存里塞，触发ERROR 701: There is insufficient system memory。
常见诱因：
- 没对JOIN字段执行
UPDATE STATISTICS，尤其在大批量导入后 - 使用
datetime而非datetime2做关联，隐式转换让统计直方图失效 - WHERE条件含
GETDATE()或变量参数，导致参数嗅探失准，预估彻底跑偏
怎么让SQL Server别乱切HASH JOIN？
禁用自适应连接是最直接的止血手段，但不能全局关——只对高危语句加查询提示更安全。
实操建议：
- 在问题SQL末尾加
OPTION (USE HINT('DISABLE_BATCH_MODE_ADAPTIVE_JOINS'))，强制保持原计划类型 - 若已知左表小、右表大且有索引，显式指定
OPTION (LOOP JOIN)，避免优化器“好心办坏事” - 检查执行计划XML里是否有
1
LEFT JOIN导致结果集爆炸，和内存溢出什么关系？
LEFT JOIN本身不占内存，但它保留左表全部行，会放大右表匹配失败时的null填充开销——尤其当右表是宽表（含xml、varchar(max)字段），每行null仍要分配完整结构体。10万左表行 × 2KB宽表结构 = 200MB内存打底，再叠加并发，OOM就来了。
必须检查的点：
- 右表是否真需要全字段？改成
SELECT u.id, u.name而非SELECT u.* - 是否存在多对一却写成LEFT JOIN？比如
orders LEFT JOIN users，但一个user对应百条order，结果集行数=orders行数，但每行都带重复user字段，内存翻倍 - 是否误把过滤条件写在ON里？
LEFT JOIN logs l ON o.id = l.order_id AND l.status = 'done'会导致logs未匹配时也保留order，但若想只查“已完成订单”，应改用INNER JOIN+ WHERE
跨库JOIN（Linked Server）拉数据拉到内存爆掉怎么办？
SQL Server对Linked Server默认不推WHERE/JOIN下推，而是把远程表全量拖回本地再算——哪怕你只想要10行，也可能先载入50万行原始数据进内存。流量和内存占用都取决于远程表大小，和最终结果无关。
绕过方式只有两个：
- 用
OPENQUERY强制下推：SELECT * FROM OPENQUERY(LS1, 'SELECT id, name FROM db.dbo.users WHERE created > ''2026-08-01''')，注意单引号要双写，且不能用四部分命名 - 分步走临时表：
SELECT user_id INTO #tmp_ids FROM remote_db... WHERE ...，再用#tmp_ids和本地表JOIN——控制第一步拉取量在1万行内，避免本地内存先撑爆
真正难处理的是JOIN字段类型不兼容，比如远程MySQL的DATETIME和本地datetime2比较，SQL Server会拒绝下推，默默切回全量拉取。此时必须在OPENQUERY里显式CONVERT(varchar, created, 120)转成字符串对齐。
