多表JOIN内存暴涨的根源是执行计划选择低效连接策略，如嵌套循环或Hash Join中间结果集失控，叠加索引缺失、驱动表顺序不当、join_buffer_size或work_mem配置不合理，导致内存指数级增长乃至OOM。

JOIN 多张表时内存暴涨的底层原因

不是“表多就一定爆内存”，而是执行计划选了低效连接策略，尤其当优化器误判小表为大表、或缺少有效索引时，会退化成嵌套循环（Nested Loop）——每增加一张表，内存占用可能呈指数级增长。MySQL 默认用 Block Nested-Loop（BNL），PostgreSQL 用 Hash Join 或 Merge Join，但无论哪种，中间结果集一旦膨胀，work_mem 或 join_buffer_size 就会被迅速吃光。

MySQL 的 join_buffer_size 与隐式全表扫描陷阱

MySQL 在没有可用索引驱动关联字段时，会对非驱动表启用 join buffer 缓存整张表（或满足条件的行）做匹配。连续 JOIN 5 张表，若其中 3 张都走全表扫描+buffer 加载，join_buffer_size（默认仅 256KB）根本不够用，系统会反复申请内存、触发 swap，最终 OOM。

• 检查是否命中索引：EXPLAIN 中看 type 是否为 ALL 或 index，且 key 列为空
• 驱动表顺序很重要：把过滤后行数最少的表放在 FROM 最左侧，让后续 JOIN 有更小的输入集
• join_buffer_size 是 per-connection 参数，不能盲目调大——它不共享，100 个并发连接各占一份

PostgreSQL 的 work_mem 溢出机制

PostgreSQL 对每个排序、Hash、Materialize 操作单独分配 work_mem。一次五表 JOIN 若触发多个 Hash Join，就会消耗 5×work_mem；如果某张维度表本身较大（比如千万级地区码表），Hash 表构建阶段就可能直接溢出到磁盘，日志里出现 hash-join: writing to disk，性能断崖下跌，同时临时文件持续占内存缓存。

• 用 EXPLAIN (ANALYZE, BUFFERS) 看实际内存/磁盘使用，重点关注 Hash Cond 和 Rows Removed by Filter
• 避免在 JOIN 条件中用函数或表达式（如 UPPER(t1.code) = t2.code），这会让索引失效，强制走 Seq Scan + Hash
• 对高频 JOIN 的维度字段，确保两边数据类型严格一致（比如都是 TEXT，而非一边 VARCHAR(32) 一边 CHAR(32)）

真正危险的不是“5张表”，而是中间结果集失控

五表 JOIN 的逻辑结果集大小 = 表1行数 × 表2匹配率 × 表3匹配率 × ……。如果其中一张维度表是“全量城市”（3000 行），另一张是“全量时间粒度”（10000 行），而业务没加时间范围过滤，中间结果轻松破亿行——这时候内存只是第一个倒下的环节，磁盘 I/O 和网络传输也会卡死。

• 永远在最外层加 WHERE 过滤，别指望 JOIN 后再 LIMIT ——优化器通常不会提前剪枝
• 考虑用物化视图或宽表预聚合替代实时多维 JOIN，尤其是报表类查询
• 对超大维度表（如用户标签宽表），优先走 LEFT JOIN ... ON ... AND condition 把过滤下推，而不是 WHERE 后置