数据库JOIN大表时内存暴增的根源是默认将被驱动表全量载入内存建哈希表或嵌套循环匹配，而非JOIN语法本身；千万行宽表加载即数百MB，多并发易触发OOM Killer杀进程。
JOIN大表时数据库到底在内存里干了什么
不是“JOIN语法本身吃内存”，而是主流数据库（MySQL/PostgreSQL）执行JOIN时，默认把被驱动表（右表）尽可能载入内存建哈希表或做嵌套循环匹配。一张千万行、字段宽（含TEXT或多个VARCHAR(2000)）的表，全量加载就是几百MB起步。一旦并发几个查询，物理内存直接打满，系统OOM Killer就会杀掉mysqld或postgres进程。
典型错误现象包括：ERROR 1038 (HY001): Out of sort memory（MySQL）、ERROR: out of memory（PostgreSQL）、Lost connection to MySQL server during query，或者SHOW PROCESSLIST里卡在Sending data或Copying to tmp table状态。
- MySQL 8.0.22+ 默认用Hash Join，
join_buffer_size参数已基本失效；老版本若EXPLAIN显示type=ALL且Extra含Using join buffer (Block Nested Loop)，才是它真在起作用 - PostgreSQL中每个
HASH JOIN、GROUP BY、ORDER BY都会独立申请一份work_mem，一个复杂查询可能消耗3倍以上 - 视图或子查询里写JOIN，容易触发物化临时表膨胀——外层没加
LIMIT，数据库就得先把整个中间结果存进内存或磁盘临时文件
为什么调大work_mem或join_buffer_size反而更危险
盲目堆内存参数是最快引发全局OOM的方式。它不解决根本问题，只让崩溃来得更慢、更隐蔽。
- MySQL的
join_buffer_size是**每连接独占**：设成4MB，max_connections=500时理论峰值就2GB；设到64MB，500连接就是32GB，远超常见服务器内存 - PostgreSQL的
work_mem是**每个操作单独申请**：一条SQL里有JOIN + ORDER BY + GROUP BY，可能同时吃掉3份work_mem；设成256MB，10个并发就2.5GB，而且这部分内存PG不还给OS - 这些参数对已走索引的JOIN完全无效——
EXPLAIN里type是ref或eq_ref，说明早用上索引了，再调join_buffer_size只是浪费
真正有效的三类解法，按优先级排序
核心逻辑是：不让数据库有机会把大表全拉进内存。控制中间结果集大小，比堆内存更可控。
-
加索引：确保被驱动表的关联字段（如
users.id、orders.user_id）有主键或二级索引；复合查询要建覆盖索引，比如WHERE status = 'active' ORDER BY created_at DESC对应(status, created_at) -
改写为分批主键查询：左表必须有单调主键（如
id BIGINT PRIMARY KEY），先取一批ID：SELECT id FROM orders WHERE id BETWEEN 10001 AND 20000，再用这批ID精准IN查右表；批次建议从5000起调，避免触发max_allowed_packet -
前置过滤子查询：别写
FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active'（先笛卡尔积再过滤），改成FROM orders o JOIN (SELECT id FROM users WHERE status = 'active') u ON o.user_id = u.id，让优化器先筛出几百个ID再JOIN
最容易被忽略的细节：应用层怎么传ID列表
不是所有“分批”都安全。应用代码里拼超长IN列表，会踩两个坑：
- MySQL默认
max_allowed_packet=4MB，20000个数字拼成字符串轻松超限，直接报错 - 数据库可能放弃使用索引，退化为全表扫描——尤其当
IN列表过长时，优化器认为走索引成本更高 - Java要用
PreparedStatement批量绑定参数，Python用executemany()；PostgreSQL推荐用VALUES构造：WHERE o.user_id IN (SELECT id FROM (VALUES (1),(2),...,(5000)) AS v(id))
分批不是万能解药，但它是唯一能把内存占用压到确定范围内的手段。索引没建好，分批也救不了；批次设太大，又回到原点。关键在EXPLAIN里看rows和Extra，而不是靠猜。
