resource_semaphore和resource_semaphore_query_compile等待本质是内存授予与可用额度错配，非单纯内存不足；top+order by因全表排序估算触发过大内存申请，索引缺失、统计过期、参数嗅探及offset/fetch分页加剧问题。
SQL Server 2019 存储过程中出现大量 RESOURCE_SEMAPHORE 或 RESOURCE_SEMAPHORE_QUERY_COMPILE 等待，本质是查询请求的内存授予（memory grant）超出了当前可用内存池额度，导致语句排队等待——这不是“内存不够”那么简单，而是内存调度策略与查询实际需求严重错配。直接加内存或调高 max server memory 往往无效，甚至恶化争用。
为什么 TOP + ORDER BY 会触发过大内存授予
SQL Server 为含 TOP 的排序操作（如 SELECT TOP 1000 * FROM t ORDER BY created_at DESC）预估内存时，会按**全表扫描+全排序**估算，而非按 TOP 数量。哪怕只取 10 行，若表有千万行且无合适索引，优化器仍可能申请数百 MB 内存。
- 典型诱因：未在
ORDER BY字段上建覆盖索引，或索引未包含SELECT所需列，迫使 SQL Server 回表+排序 - 执行计划中看到
Sort或Top N Sort算子，且Estimated Row Count远高于实际返回行数，就是信号 - 用
DBCC TRACEON(8649)强制并行或OPTION (RECOMPILE)有时反而放大问题——重编译后统计信息更“悲观”，授予更大内存
用 OFFSET/FETCH 替代 TOP 时的内存陷阱
OFFSET 10000 ROWS FETCH NEXT 100 ROWS ONLY 看似优雅，但 SQL Server 必须先跳过前 10000 行，内部仍需维护完整排序结果集的内存结构。数据量越大，OFFSET 越深，内存授予越失控。
- 当
OFFSET值超过 5 万，内存授予常突破 1 GB，且 CPU 解析开销陡增 - 该语法无法利用索引跳过，必须物理扫描前 N 行；而
TOP+ 键值推进可走索引 Seek - 若必须用分页，优先改用键值分页（keyset pagination）：记录上一页最大
id，下一页查WHERE id > @last_id ORDER BY id LIMIT 100
显式控制内存授予的三个有效手段
SQL Server 不允许直接指定内存大小，但可通过 Hint 和结构设计间接约束：
- 对已知小结果集的排序，加
OPTION (FAST 100)：提示优化器优先快速返回前 100 行，通常抑制大排序，改用嵌套循环+索引查找 - 避免在存储过程中拼接动态 SQL 后再执行排序——参数化缺失导致重编译频繁，统计信息不准，内存估算漂移；改用固定语句 + 参数化输入
- 对聚合类操作（如
GROUP BY大字段），显式用OPTION (HASH GROUP, HASH JOIN)避免内存密集型 Sort-based 算法；但需确认 hash 桶足够，否则退化成 spill 到tempdb
最容易被忽略的根源：统计信息陈旧 + 参数嗅探
一个本该只返回 10 行的查询，因统计信息过期，优化器误判会返回 10 万行，于是申请 2 GB 内存——而真实执行时只用了 10 MB，其余 1990 MB 被锁住、不可复用，直接卡住其他查询。
- 检查
sys.dm_exec_query_stats中last_grant_kb与last_used_grant_kb差距是否巨大（如 2000000 vs 12000） - 在存储过程开头加
UPDATE STATISTICS仅针对关键大表，别全库更新；或用WITH FULLSCAN确保精度 - 对多分支逻辑（如
IF @type = 'A'），拆成独立存储过程，避免单过程内不同参数路径共享同一执行计划和内存授予
