PostgreSQL中JOIN导致OOM，主因是work_mem过小、连接池过大、JOIN字段缺失索引及分页方式不当；需协同调优这四方面。
JOIN大表时OOM了，先看work_mem设了多少
PostgreSQL里一个JOIN爆内存，十有八九不是SQL写得烂，而是work_mem太小，导致本该走哈希连接的被迫退化成嵌套循环，或者哈希表被切片溢出到磁盘后反复读写。默认值通常只有4MB，对千万级关联根本不够用。
实操建议：
-
SET work_mem = '256MB'是临时调优最直接的手段，但只对当前会话生效； - 在
postgresql.conf里改全局值要谨慎——每个并发查询都会独占一份work_mem，100个连接 × 256MB = 25GB，可能直接把机器拖垮； - 更稳妥的做法是：在关键查询前加
SET LOCAL work_mem = '512MB'，执行完自动恢复； - 用
EXPLAIN (ANALYZE, BUFFERS)确认是否真用了哈希连接，且Hash行里没出现disk字样。
连接池配太大反而让JOIN更慢
像pgbouncer或HikariCP这类连接池，如果maxPoolSize设到100+，而数据库max_connections又没同步扩容，就会触发连接争抢。更隐蔽的问题是：每个连接都带着自己的work_mem预算，高并发下内存瞬间打满，系统开始swap，JOIN操作卡在IO上。
实操建议：
- 把连接池
maxPoolSize压到数据库max_connections的60%以内，比如DB允许200连接，池子最多配120； - 禁用
pgbouncer的transaction模式下自动SET语句（如client_encoding），它可能干扰你手动设的work_mem； - HikariCP里关掉
connectionInitSql，避免每次拿连接都执行一次SET，造成额外开销； - 观察
pg_stat_activity里state = 'idle in transaction'的连接数，这类连接长期占着work_mem不放，得从应用层清理。
JOIN字段没索引？别光盯着work_mem
很多人调大work_mem后发现没改善，回头一看EXPLAIN里全是Seq Scan——说明数据库连过滤都靠扫全表，JOIN前的数据集就已经超大，再怎么调内存也白搭。
实操建议：
- 对所有
JOIN ... ON和WHERE里的字段，检查是否建了联合索引，顺序要和JOIN条件一致，比如JOIN t1 ON t1.a = t2.a AND t1.b = t2.b，索引就得是ON t1(a,b)； - 用
pg_stats查n_distinct，如果某列唯一值极少（比如状态字段只有3个值），建索引反而可能被优化器忽略； - 分区表JOIN时，确保分区键参与关联条件，否则优化器无法裁剪，
work_mem再大也救不了跨几十个分区的扫描。
应用层做分页JOIN？小心LIMIT骗过优化器
常见写法：SELECT * FROM a JOIN b ON ... ORDER BY a.id LIMIT 20 OFFSET 1000。看起来只取20条，但PostgreSQL可能先完成整个JOIN再排序截断，中间结果集依然吃满内存。
实操建议：
- 用键集分页替代
OFFSET：记录上一页最大a.id，下一页写WHERE a.id > 12345，让JOIN能尽早终止； - 如果必须用
LIMIT，在EXPLAIN里确认Limit节点是否包在Hash Join外面——如果是，说明优化器已下推；如果Limit在最外层，就危险； - 对宽表JOIN，考虑提前投影：
SELECT a.id, b.name比SELECT *少传数据、少占内存，尤其当某些字段是jsonb或text大字段时。
真正卡住的往往不是单点配置，而是work_mem、连接池大小、索引覆盖、分页方式这四者之间的耦合。调其中一个之前，先看另外三个有没有在拖后腿。
