直接结论：不是join语法本身吃内存，而是数据库执行时默认把被驱动表全量载入内存建哈希表或做嵌套循环匹配；mysql中join_buffer_size仅对无索引的all/index型join生效且线程独占，postgresql中work_mem是每个哈希/排序操作独立申请，sql server的hash join则因类型不匹配易触发全表加载导致oom。
直接结论：不是JOIN语法本身吃内存，而是数据库执行时默认把被驱动表（右表）全量载入内存建哈希表或做嵌套循环匹配——一张千万行宽表加载即数百MB，几个并发就触发OOM Killer杀进程。
MySQL里EXPLAIN显示type=ALL时，join_buffer_size才真起作用
这个参数只对没走索引的等值JOIN生效，且是每连接独占。比如设成4MB，max_connections=500，理论峰值就是2GB；设到64MB，500连接直接32GB。但现实中，只要被驱动表的ON字段有索引（如users.id），优化器根本不会用join_buffer_size，而是走ref或eq_ref——这时调它纯属浪费，还挤占innodb_buffer_pool_size。
常见误判点：
- 看到“Using join buffer (Block Nested Loop)”就盲目调大
join_buffer_size，却没检查EXPLAIN里type是不是ALL - MySQL 8.0.22+ 默认禁用Block Nested-Loop，改用Hash Join，
join_buffer_size已基本失效 - 在存储过程中用游标+大表JOIN，
sp_head::main_mem_root内存不自动释放，哪怕过程退出也挂着
PostgreSQL中一个查询可能吃掉3份work_mem
work_mem不是“给整个查询分配的内存”，而是每个哈希操作（HASH JOIN）、排序（ORDER BY）、聚合（GROUP BY）各自独立申请一份。一条SQL含JOIN + ORDER BY + GROUP BY，就可能同时消耗3倍work_mem。
更危险的是：这部分内存PG不归还OS，只由自己管理。设成256MB，10个并发就2.5GB，且无法回收。
实操建议：
- 别在
postgresql.conf里全局设>64MB；高并发下优先加索引，而非堆内存 - 用
SET LOCAL work_mem = '32MB'包裹单条查询，比会话级更安全 - 查
EXPLAIN (ANALYZE, BUFFERS)，看有没有disk: NkB——有，说明已spill to disk，再调work_mem才有意义
视图或子查询里写JOIN，容易触发物化临时表膨胀
数据库看到SELECT * FROM (SELECT ... FROM a JOIN b ...) t WHERE ...，常会先把子查询结果物化成临时表。如果外层没加LIMIT或过滤条件弱，中间结果集可能比原表还大——尤其当字段含TEXT或多个VARCHAR(2000)时，内存/磁盘临时文件瞬间暴涨。
典型错误现象：
-
ERROR: out of memory或Lost connection to PostgreSQL server -
SHOW PROCESSLIST卡在Copying to tmp table（MySQL）或Hashing tuples（PG） - 视图定义里嵌了
IN (SELECT ...)，外层10万行 → 内层执行10万次全表扫描
解法不是换语法，而是控制中间结果大小：先用主键范围分批取ID，再用IN精准拉关联数据，批次控制在5000以内。
SQL Server默认选HASH JOIN，但内表类型不一致就强制全加载
SQL Server对大表JOIN倾向选HASH JOIN，但它会把整个内表（右表）哈希载入内存。一旦字段类型不匹配——比如orders.user_id INT对users.id BIGINT——触发隐式转换，索引失效，优化器只能退回到HASH，内存用量直接翻倍。
真正可控的替代方案是MERGE JOIN：只要两边JOIN列都有B-tree索引且顺序一致（都ASC或都DESC），它就逐行归并，内存占用恒定。
但必须满足：
-
orders(user_id)和users(id)都建了索引，且方向一致 - 显式加
ORDER BY o.user_id，让优化器看到“已排序路径” - 用
OPTION (MERGE JOIN)提示，但缺索引时会报错Query processor could not produce a query plan
复杂点在于：不同数据库对“内存”的定义完全不同——MySQL的join_buffer_size、PostgreSQL的work_mem、SQL Server的hash_join内存池，彼此不兼容，也不能互相参考。最容易被忽略的是：调参前不看EXPLAIN，不确认当前执行路径是否真依赖该参数。
