Msg 701 报错本质是运行时内存申请被 internal 资源池拒绝，非内存不足；根本原因是统计信息陈旧导致内存预估严重偏高，叠加临时表全驻内存、未分段处理等，使单次申请超阈值。
Msg 701 报错不是内存不够，是 SQL Server 在执行时拿不到预估的内存 —— 加物理内存、调 pagefile.sys、清缓存（DBCC FREEPROCCACHE）全无效。
为什么 DBCC FREEPROCCACHE 后首次慢、后续秒错
这说明问题不在编译阶段，而在运行时内存申请环节。SQL Server 执行计划里已为 SORT 或 HASH JOIN 预留了内存额度，但 runtime 发现 resource pool 'internal' 拒绝分配，直接失败。复用失败计划后不再重试，所以第二次立刻报错。
- 典型表现：
GetAllRevisions_Monthly第一次跑一分钟才出Msg 701（卡在内存等待），第二次瞬间失败 - 根本原因：统计信息陈旧 → 优化器误判数据量 → 预留内存远超实际所需
- 临时表写法不当（如未分页的
SELECT INTO #temp）→ 中间结果集全驻内存，不释放
分段处理的关键位置在哪
不是随便切数据，而是切在最耗内存的操作之前。目标是让每次执行只申请自己那部分所需的内存，避开 internal 资源池的硬阈值。
- 对含
ORDER BY ... OFFSET/FETCH的分页，改用游标式分页：WHERE id > @last_id ORDER BY id ASC TOP 1000，避免全量排序 - 对大表
JOIN，先用WHERE缩小驱动表范围（比如加时间范围过滤），再 join - 避免嵌套过深的 CTE，尤其带聚合或排序的；能转成物化临时表就显式
CREATE TABLE #t+INSERT
MEMORY_OPTIMIZED 临时表能不能救急
基本不能，还可能让问题更隐蔽。
- 内存优化表（
SCHEMA_ONLY）内存常驻、不可被动态回收，不参与 internal 资源池配额协商 - SQL Server 2008 不支持；2014+ 版本中仅适用于短生命周期、高并发 OLTP 场景，非大数据批处理
- 缺乏统计信息 → 优化器生成更差执行计划 → 内存预估更离谱
- 若真要用，必须搭配
SCHEMA_ONLY，否则 CHKPT 文件又占磁盘空间
真正有效的干预点只有三个：控制单次内存申请上限（分段）、压制错误预估（OPTION (RECOMPILE) + 更新统计信息）、抑制并行（OPTION (MAXDOP 1)）。复杂点在于，这些手段要组合使用，且必须在最耗资源的操作节点上生效 —— 离开具体执行计划谈优化，全是纸上谈兵。
