SQL报表内存不足主因是work_mem等参数过小致磁盘溢出，调优应先通过EXPLAIN和日志确认spill to disk证据，再按并发反推合理设置work_mem，辅以会话级动态调整和SQL写法优化。
SQL报表查询出现内存不足，通常不是因为物理内存真的不够，而是数据库为单个查询分配的内存上限（如 work_mem、sort_mem、hash_mem 等参数）过小，导致大量数据被迫落盘（spill to disk），进而拖慢查询甚至报错“out of memory”。调优关键在于合理分配内存资源，而非盲目加大。
确认瓶颈是否真在内存
先别急着改参数，得验证问题根源：
- 查看执行计划（EXPLAIN (ANALYZE, BUFFERS)），重点关注是否有 Sort、Hash Join 或 Aggregate 节点显示 "disk: XXXkB" —— 这说明已发生磁盘溢出，是内存不足的直接证据
- 检查 PostgreSQL 日志（或 SQL 返回错误），是否含 "out of memory"、"could not resize shared memory segment" 等提示
- 对比同一查询在小数据集上是否正常——若仅大数据量失败，大概率是 work_mem 不足，而非系统内存告急
核心内存参数调优（PostgreSQL 示例）
PostgreSQL 中影响报表类查询内存的关键参数主要是 work_mem，它控制每个内部操作（排序、哈希、聚合）可使用的内存量：
- work_mem：默认常为 4MB。报表中多层 GROUP BY、ORDER BY、窗口函数或大表 JOIN 容易耗尽。建议按并发查询数反推：总可用内存 ÷ 预估最大并发数 ÷ 2～3（留余量）。例如：64GB 内存、峰值 20 并发，可设为 128MB（64×1024÷20÷3≈109）
- maintenance_work_mem：影响 VACUUM、CREATE INDEX 等维护操作，报表导出后做索引优化时可能涉及，一般设为 1–2GB 即可
- shared_buffers：不建议为报表单独调高（它是全局缓存，与查询内存无直接关系），保持 25% 物理内存较稳妥，过度增大反而降低 OS 缓存效率
会话级临时调优更安全
报表查询往往偶发、数据量波动大，全局调大 work_mem 可能引发内存争抢。推荐在 SQL 执行前动态设置：
- 连接后立即执行：SET LOCAL work_mem = '512MB';（仅对当前事务生效）
- 在报表工具（如 Power BI、Tableau、自研后台）的查询前缀中加入该语句，不影响其他业务查询
- 避免使用 SET work_mem（无 LOCAL），否则会影响整个会话后续所有查询，风险较高
配合查询写法减少内存压力
再好的参数也扛不住低效 SQL。从源头降低内存需求同样关键：
- 用 LIMIT + OFFSET 分页时，避免深度分页（如 OFFSET 100000）。改用基于游标的分页（WHERE id > last_id）或物化中间结果
- 大表 JOIN 前，确保关联字段有索引；必要时先用 WHERE 过滤再 JOIN，而不是 JOIN 后 WHERE
- 避免 SELECT *，只取报表真正需要的列；TEXT/JSON 类大字段尽量延迟加载或单独查询
- 复杂报表可拆成多个 WITH 子句（CTE），但注意 PostgreSQL 12+ 默认会物化 CTE，反而增加内存开销——加 MATERIALIZED 或 NOT MATERIALIZED 显式控制
