sql 复杂报表内存溢出本质是单次数据量超内存承载，应改用分批统计、游标式分页、物化预计算等“查得更轻”策略，禁用 order by rand()等隐性内存杀手。
SQL 复杂报表出现内存溢出，本质是单次加载或计算的数据量远超数据库或应用层内存承载能力。直接优化 SQL 写法往往收效有限，更有效的方式是改变执行逻辑：用分批统计替代全量聚合，用显式游标（或等效分页机制）替代一次性扫描。关键不在“怎么查得更快”，而在“怎么查得更轻”。
分批统计：按维度切分 + 增量聚合
适用于需跨大表关联、多层级 GROUP BY、窗口函数嵌套的场景。核心思路是避免单 SQL 处理全部数据，转为按业务主键（如日期、区域、客户分组 ID）分片执行。
- 将时间范围拆成天 / 周 / 月粒度，逐段执行 SUM/COUNT/AVG，结果存入临时汇总表，最后再做顶层聚合
- 对用户类报表，先按 customer_segment_id 分组，每批处理 1000 个分段，避免 JOIN 时笛卡尔积爆炸
- 使用 CTE + LIMIT/OFFSET（或 ROW_NUMBER()分页）模拟分批，但注意 OFFSET 深翻性能差，优先用基于主键 / 时间字段的游标式分页（如WHERE create_time > ? ORDER BY create_time LIMIT 1000）
游标优化：显式控制数据流，拒绝全集缓存
数据库游标本身不解决内存问题，但配合应用层控制，可把“查完再算”变成“边取边算”。重点在于不让结果集在内存中堆积。
- 禁用 JDBC 默认的 ResultSet.TYPE_FORWARD_ONLY 全缓存模式，改用 TYPE_FORWARD_ONLY + CONCUR_READ_ONLY 并设置setFetchSize(100)，让驱动按需拉取
- 存储过程中用 DECLARE CURSOR … FETCH NEXT 逐行或逐块处理，每处理 N 行就 COMMIT 一次，避免事务日志和 PGA 内存持续增长
- 替代方案：用 SELECT … INTO OUTFILE 导出中间结果到磁盘，再由脚本分段读取计算，彻底绕过内存瓶颈
绕过 SQL：用物化视图 + 定时预计算
对 T + 1 或准实时报表，与其每次硬扛复杂 SQL，不如把计算压力前移到非高峰时段。
- 将多表 JOIN+ 聚合逻辑封装为物化视图（Oracle）或物化 CTE（PostgreSQL 15+），每日凌晨刷新
- 在 MySQL 中可用汇总表 +EVENT 调度，例如每小时跑一次INSERT INTO rpt_daily_summary … SELECT … GROUP BY date, region
- 查询时只查预计算表，响应从分钟级降到毫秒级，内存占用趋近于零
必须检查的隐性内存杀手
有些操作看似简单，却会触发全表缓存或重复计算，导致 OOM 被误判为 SQL 复杂度问题。
- ORDER BY RAND()：强制排序所有行，即使只取 1 条，也需载入全量数据
- SELECT * + 应用层过滤：数据库返回全部字段（含 TEXT/BLOB），网络传输和 JVM 堆都吃紧
- 未加 WHERE 条件的 COUNT(*)：InnoDB 需遍历聚簇索引，MyISAM 虽快但不支持事务，且无法应对高并发更新
