直接调大sort_buffer_size或work_mem几乎没用，真正有效的是用主键分批+精准IN替代一次性JOIN，前提是左表主键单调、右表关联字段有索引，避免数据库将千万级右表全载入内存导致OOM。
直接调大 sort_buffer_size 或 work_mem 几乎没用，真正有效的手段是绕开数据库一次性加载全量关联数据的执行模型。
为什么 JOIN 大表会触发内存溢出而非单纯变慢
数据库（尤其是 MySQL 的 Block Nested Loop、PostgreSQL 的 Hash Join）默认把右表（被驱动表）尽可能载入内存做匹配。当右表是千万级宽表（含 TEXT、多个 VARCHAR(2000)），单次 JOIN 就可能吃掉数 GB 内存——这时报错常是 Out of sort memory 或 Lost connection，但根源根本不是排序，而是哈希构建阶段爆内存。
- MySQL 报
ERROR 1038 (HY001): Out of sort memory？大概率是 JOIN 或 GROUP BY 触发了临时表膨胀，sort_buffer_size完全不参与这个过程 - PostgreSQL 报
out of memory且EXPLAIN (ANALYZE, BUFFERS)显示Hash节点下有disk: N kB？说明哈希表已落盘，再调work_mem只会让落盘更晚，不解决根本问题 - 视图或子查询里嵌套 JOIN，单独跑子查询正常，一 JOIN 就崩？极可能是物化中间结果集失控，和排序缓冲区无关
用主键分批 + 精准 IN 替代一次性 JOIN
核心是把“数据库端大连接”转为“应用层可控小查询”，关键前提是左表主键连续、右表关联字段有索引。
- 左表必须有单调递增/递减主键（如
id BIGINT PRIMARY KEY AUTO_INCREMENT），否则无法安全切片 - 右表必须在关联字段（如
user_id）上有索引；若没有，每次IN都退化成全表扫描 - 批次大小从
5000起步，观察Slow Log中Rows_examined和执行时间，逐步放宽到10000–20000 - 避免应用层拼超长
IN列表：Java 用PreparedStatement批量绑定，Python 用executemany()；MySQL 8.0+ 可建临时表，PostgreSQL 推荐用VALUES构造集合
用前置过滤子查询替代 IN/EXISTS
直接把 WHERE user_id IN (SELECT id FROM users WHERE status = 'active') 改成 JOIN 并不安全——优化器很可能先全量 JOIN 再过滤，中间结果爆炸。
- 必须写成
FROM orders o JOIN (SELECT id FROM users WHERE status = 'active') u ON o.user_id = u.id，强制先执行子查询筛出几百个 ID - 确保
users(status, id)有覆盖索引，否则子查询本身又变慢，还可能因回表放大内存压力 - 注意 NULL 行为差异：
IN遇到user_id IS NULL自动跳过，JOIN 同样丢弃，但如果业务逻辑依赖三值逻辑（比如显式处理NOT (user_id IN ()) OR user_id IS NULL），结果可能不一致 - 子查询结果若稳定在几十万行以上，连这种改写也不够——得上分页拉取 ID：
SELECT id FROM users WHERE status = 'active' ORDER BY id LIMIT 5000 OFFSET 0
最容易被忽略的底层限制
所有分批方案都依赖一个前提：数据库客户端能真正流式读取结果，而不是把整页数据缓存在 JVM 堆或本地内存里。
- MySQL JDBC 必须加参数：
?useCursorFetch=true&defaultFetchSize=100，否则ResultSet默认把全部结果集加载进内存 - PostgreSQL JDBC 要设
fetchSize > 0且setAutoCommit(false)，否则游标无效 - SQL Server 需启用
SET NOCOUNT ON并用Statement.setFetchSize()控制批次 - 别信“加了
LIMIT就安全”——如果ORDER BY字段没索引，数据库仍要全表排序后才取前 N 行，内存照样爆
