SQL子查询结果太大内存溢出怎么办？分批提取与游标应用
数据库查询突然卡住、连接断开，甚至直接报出内存不足的错误？这很可能不是你的SQL写错了，而是遇到了一个典型的性能陷阱：子查询结果集太大，直接把内存撑爆了。简单来说，当你执行类似 SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 WHERE ...) 的查询时，数据库会试图把括号里那个子查询的所有结果一股脑儿加载到内存里进行匹配，结果集一旦过大，内存溢出（OOM）就在所难免。
子查询结果太大导致内存溢出的典型表现
无论是MySQL还是PostgreSQL，症状都颇为相似。执行包含大结果集子查询的语句时，查询会长时间“卡住”，随后可能遇到连接断开（比如MySQL的 ERROR 2013 (HY000): Lost connection to MySQL server during query），或者直接抛出 Out of memory 错误。在PostgreSQL中，除了明确的错误信息，进程甚至可能被系统的 oom_killer 直接终止。这本质上不是语法问题，而是数据库执行计划为了做哈希连接或嵌套循环，不得不将整个子查询结果物化到内存中所导致的资源耗尽。
用 LIMIT + OFFSET 分批提取替代一次性子查询
对于数据导出、批量迁移这类允许分段处理的任务，分批提取是个直接有效的思路。核心逻辑就是“化整为零”，把那个庞大的子查询拆分成一个个小块，分批喂给主查询。
- 第一步，摸清底数：先执行
SELECT COUNT(*) FROM t2 WHERE ...，了解总数据量，方便规划批次。 - 第二步，循环分页：利用
LIMIT和OFFSET分批获取ID。例如，每次取5000行：SELECT id FROM t2 WHERE ... ORDER BY id LIMIT 5000 OFFSET 0，下次OFFSET 5000，依此类推。 - 第三步，分批关联：拿到每批ID列表后，执行主查询：
SELECT * FROM t1 WHERE id IN (1,2,3,...,5000)。这里有个细节要注意：IN列表的长度不能超过数据库的限制（例如MySQL受max_allowed_packet参数制约）。 - 性能小贴士：如果ID是连续的整数且建有索引，用范围查询
SELECT * FROM t1 WHERE id BETWEEN ? AND ?替代IN列表，性能往往更稳定。
PostgreSQL 中用游标（CURSOR）流式读取大结果集
当子查询逻辑复杂、难以改写，但又必须处理全量数据时，PostgreSQL的游标（CURSOR）就派上用场了。游标的工作方式是“流式”的，它不会一次性把所有结果加载到内存，而是按需抓取（fetch），完美规避内存瓶颈。
- 声明游标：首先，在一个事务中声明一个命名游标：
DECLARE batch_cursor CURSOR FOR SELECT id FROM t2 WHERE ...。 - 分批抓取：然后，通过
FETCH 1000 FROM batch_cursor这样的命令，每次只从服务端获取1000行ID。 - 应用层循环处理：在应用程序中，循环执行“抓取ID -> 构造IN查询 -> 查询t1表 -> 处理结果”这个过程，直到
FETCH返回空数据为止。 - 重要提醒：游标需要在事务内使用（以
BEGIN;开始，COMMIT;结束），否则可能会被自动关闭。同时，长时间打开游标不处理会占用服务端资源，需要留意。
MySQL 没有标准游标？用临时表 + 自增偏移模拟分批
MySQL在交互式客户端中并不直接支持类似PostgreSQL的游标操作，存储过程里的游标用起来又比较繁琐。一个更通用的替代方案是“临时表结合分页”。
- 创建临时仓库：先把子查询的结果存到一个临时表里：
CREATE TEMPORARY TABLE t2_ids AS SELECT id FROM t2 WHERE ...。 - 建立索引：为了后续分页查询更快，记得给临时表的ID字段加个索引：
ALTER TABLE t2_ids ADD INDEX idx_id (id)。 - 变量控制分页：接下来，就可以用变量配合
LIMIT/OFFSET安全地分批了：SELECT id FROM t2_ids ORDER BY id LIMIT 5000 OFFSET @offset，在应用层循环中递增@offset的值即可。 - 注意临时表特性：临时表生命周期与数据库会话绑定，会话结束会自动删除，无需手动清理。但要关注磁盘空间，因为当临时表大小超过
tmp_table_size或max_heap_table_size的设置时，它会被写入磁盘，影响性能。
最后必须说，无论是分批还是游标，都属于“事后补救”的优化手段。它们都有各自的代价：OFFSET 在分页很深时效率会降低，游标依赖事务上下文，临时表则要注意资源消耗。在考虑这些复杂方案之前，最应该问自己的是：这个子查询真的需要返回全部数据吗？ 很多时候，回头审视一下查询条件，加一个有效的 WHERE 过滤，提前砍掉90%的无用数据，比任何精巧的分批技术都来得根本和高效。
