sql临时内存泄漏主因是异常语句过度占用tempdb/pga/work_mem且未释放，表现为排序哈希溢出、嵌套cte失控、超长in/json解析、游标或临时表未清理。
SQL数据库出现临时内存泄漏，往往不是系统级故障，而是某些异常SQL语句在执行过程中过度占用临时内存（如tempdb、PGA、work_mem等），且未能及时释放。这类问题通常不触发报错，但会导致查询变慢、并发下降、甚至实例OOM。识别其背后的SQL特征，是快速定位和拦截的关键。
高内存消耗的排序与哈希操作
当SQL中存在大结果集的 ORDER BY、GROUP BY、DISTINCT、JOIN（尤其是HASH JOIN） 时，数据库需在内存中构建排序缓冲区或哈希表。若数据量超出内存阈值，就会 spill 到磁盘（如tempdb），但若并发多、中间结果大，仍会持续占住内存片段，形成“半悬挂”状态。
- 典型写法：对未索引字段排序千万级表；GROUP BY 多列+聚合函数+无过滤条件
- 可观测指标：执行计划中出现 “Sort (Disk)” 或 “Hash (Disk)”；session级 memory usage 持续高于 normal baseline
嵌套过深或失控的CTE/子查询
递归CTE未设 MAXRECURSION（SQL Server）或未加终止条件；多层嵌套子查询（尤其含窗口函数+聚合）可能让优化器误估中间结果集大小，导致为每一层预留过多内存，且各层生命周期重叠，释放延迟。
- 风险模式：WITH t1 AS (...), t2 AS (SELECT * FROM t1 ...), t3 AS (SELECT * FROM t2 ...)，且每层都含聚合或排序
- 建议：用 EXPLAIN ANALYZE 查看实际行数 vs 预估行数偏差；对CTE加 LIMIT 或物化提示（如 PostgreSQL 的 MATERIALIZED）
未绑定参数的大批量IN列表或JSON解析
应用拼接超长 WHERE id IN (1,2,3,...,50000)，或使用 jsonb_path_query / OPENJSON 解析超大JSON文档，会触发解析器一次性加载并构建大量内存对象。这类SQL常被缓存，但每次执行都重新分配，旧内存未及时GC。
- 特征：SQL文本长度异常（>4KB）、parse time 明显偏高、plan cache 中对应语句的 memgrant_mb 波动剧烈
- 对策：改用临时表+JOIN替代大IN；对JSON字段预拆解并建GIN索引；限制单次解析JSON大小
游标未关闭或显式临时表未显式DROP
存储过程中声明了 DECLARE CURSOR 但未配对 CLOSE/FETCH；或创建 CREATE TEMP TABLE 后流程异常退出，导致会话结束前临时对象残留。这类泄漏呈累积性，尤其在连接池复用场景下更隐蔽。
- 检查点：监控 tempdb.sys.tables（SQL Server）或 pg_temp* schema 对象数量是否随时间增长
- 实践要求：所有游标必须有 BEGIN TRY/CATCH + CLOSE；临时表创建后统一加 DROP TABLE IF EXISTS
