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虽快但不支持事务，且无法应对高并发更新
