子查询结果太大导致内存溢出的典型表现是MySQL或PostgreSQL执行IN子查询时卡住、断连或报OOM错误；应优先优化条件过滤，其次采用分批（LIMIT/OFFSET、临时表）或游标流式处理。
子查询结果太大导致内存溢出的典型表现
MySQL 或 PostgreSQL 执行 SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 WHERE ...) 时卡住、连接断开，或报错 Out of memory / ERROR 2013 (HY000): Lost connection to MySQL server during query；PostgreSQL 可能出现 ERROR: out of memory 或被 oom_killer 杀掉进程。这不是语法错误，而是数据库把子查询结果全加载进内存做哈希/嵌套循环所致。
用 LIMIT + OFFSET 分批提取替代一次性子查询
适用于主查询逻辑允许分段处理的场景（如后台导出、数据迁移），核心是把大子查询拆成小批次，每次只取几千行 ID，再拼进主查询。
- 先查出子查询的总行数：
SELECT COUNT(*) FROM t2 WHERE ... - 用循环分页拉取 ID 列表，例如每次取 5000 行：
SELECT id FROM t2 WHERE ... ORDER BY id LIMIT 5000 OFFSET 0、OFFSET 5000、OFFSET 10000…… - 每批拿到 ID 后，执行主查询：
SELECT * FROM t1 WHERE id IN (1,2,3,...,5000)—— 注意：IN 列表长度别超数据库限制（MySQL 默认max_allowed_packet限制实际可传参数大小） - 若 ID 是连续整型且有索引，可用范围替代 IN：
SELECT * FROM t1 WHERE id BETWEEN ? AND ?，性能更稳
PostgreSQL 中用游标（CURSOR）流式读取大结果集
游标不把全部结果加载进内存，而是按需 fetch，适合子查询本身无法改写但必须全量关联的场景。
- 声明命名游标：
DECLARE batch_cursor CURSOR FOR SELECT id FROM t2 WHERE ... - 分批 fetch：
FETCH 1000 FROM batch_cursor，每次只取 1000 行 ID - 在应用层循环 fetch → 构造 IN 子句 → 查询 t1 → 处理结果 → 继续 fetch，直到
FETCH返回空 - 注意：游标需在事务内使用（
BEGIN; ...; COMMIT;），否则可能被自动关闭；长时间未 fetch 会占用服务端资源
MySQL 没有标准游标？用临时表 + 自增偏移模拟分批
MySQL 存储过程虽支持游标，但不可用于交互式客户端，且嵌套复杂。更实用的是“临时表 + LIMIT/OFFSET”组合：
- 先建临时表存子查询结果：
CREATE TEMPORARY TABLE t2_ids AS SELECT id FROM t2 WHERE ... - 加索引加速后续分页：
ALTER TABLE t2_ids ADD INDEX idx_id (id) - 用变量控制偏移：
SELECT id FROM t2_ids ORDER BY id LIMIT 5000 OFFSET @offset，配合应用层递增@offset - 临时表生命周期绑定会话，不用手动清理，但要注意磁盘空间（
tmp_table_size和max_heap_table_size会影响是否落地磁盘）
分批和游标都不是银弹：OFFSET 深度越大越慢，游标依赖事务上下文，临时表要防重复创建。真正关键的是——先确认子查询是否真有必要全量执行，有时候加个 WHERE 条件过滤掉 90% 数据，比任何分批都管用。
