ERROR 701源于HASH JOIN哈希表溢出，主因是优化器估算偏差（统计信息过期、类型不一致、WHERE未下推），导致构建表全量加载内存后被迫写入tempdb；应通过控制输入规模、补索引、合理选用MERGE JOIN并验证统计信息来解决。
为什么 HASH JOIN 会突然报 ERROR 701？
不是内存总量不够，而是 SQL Server 在执行 HASH JOIN 时，把整个“构建表”（通常是右表或内表）全量加载进内存建哈希表，一旦实际行数远超优化器估算——比如统计信息过期、JOIN 字段类型不一致（INT 对 BIGINT）、WHERE 条件没下推到子查询里——哈希表就溢出到 tempdb，触发磁盘写入，进而卡死或直接报 ERROR 701。
常见现象包括：
- 同一查询第一次执行慢一分钟才失败，第二次秒报错（复用错误计划）
- 执行计划中
Hash Match算子属性显示SpillLevel > 0 -
sys.dm_db_session_space_usage中internal_objects_alloc_page_count骤增
怎么让 HASH JOIN 少吃点内存？
关键不是禁用它，而是控制输入规模和内存边界：
- 强制小表做构建表：用
OPTION (HASH JOIN, FORCE ORDER)锁定连接顺序，确保结果集更小的表在FROM左侧（注意：这会压制优化器重排，仅用于已知大小关系明确的场景） - 提前过滤再 JOIN：把
WHERE条件塞进子查询，例如INNER JOIN (SELECT * FROM orders WHERE order_date >= '2025-01-01') o ON ...，避免百万行全量参与哈希构建 - 补覆盖索引：如果构建表需读多列，建非聚集索引包含所有字段，减少回表带来的额外内存压力
- 临时限并发内存：用
OPTION (MAXDOP 1, QUERYTRACEON 9481)配合资源调控器，避免多个哈希操作争抢内存（仅限压测或紧急场景）
什么时候该换 MERGE JOIN？
MERGE JOIN 不吃内存，只要两表 JOIN 列都有已排序的 B-tree 索引（聚集索引或含该列的非聚集索引），就能逐行归并。但它不会自动被选中，得给足信号：
- 确保两边 JOIN 列索引顺序一致（都是
ASC或都是DESC） - 显式加
ORDER BY：即使业务不需要，ORDER BY o.user_id会让优化器看到“已排序路径”，倾向选MERGE JOIN - 用
OPTION (MERGE JOIN)提示，但必须先确认索引存在——缺索引时加提示会直接报错Query processor could not produce a query plan - 别和
FORCE ORDER混用：后者锁死连接顺序，可能破坏MERGE JOIN所需的双排序前提
查错和验证不能跳过的三件事
很多问题拖到报错才处理，其实早有迹可循：
- 查当前查询内存授予：运行
SELECT granted_memory_kb, used_memory_kb, max_used_memory_kb FROM sys.dm_exec_query_memory_grants，对比granted和used是否接近甚至超限 - 看执行计划是否已 spill：打开实际执行计划，点开
Hash Match属性，找SpillLevel和Actual Number of Rows是否远大于Estimated Number of Rows - 确认统计信息是否过期：对大表执行
DBCC SHOW_STATISTICS ('orders', 'IX_orders_user_id')，检查Updated时间是否超过 7 天，或数据变更超 20% 后未UPDATE STATISTICS
真正卡住的从来不是算法本身，而是估算偏差和输入失控——调大 max server memory 解不了问题，盯住统计信息、类型一致性、WHERE 下推这三个点，才能稳住 HASH JOIN 的内存胃口。
