优先改写为JOIN，只查必要字段并加索引；MySQL分页驱动或禁用BNL，PostgreSQL优选EXISTS且带关联条件；复杂场景落地为带索引的临时表。
WHERE 子查询太慢，直接爆内存怎么办
SQL 嵌套查询在数据量上百万后，WHERE id IN (SELECT id FROM ...) 这类写法极易触发临时表膨胀和内存溢出，尤其在 MySQL 5.7 或 PostgreSQL 默认配置下。根本原因不是语法错，而是优化器被迫把子查询结果全加载进内存再做匹配。
- 优先改写成
JOIN：MySQL 对IN (subquery)的物化策略不智能，而JOIN能走索引 + 流式关联 - 避免
SELECT *在子查询里：只查必要字段，减少物化行大小；比如用SELECT user_id而非SELECT * - 给子查询的
WHERE条件加索引：如果子查询里有WHERE status = 'active'，必须确保status列有索引 - PostgreSQL 用户注意：
IN (SELECT ...)在 12+ 版本默认启用哈希物化，但若子查询返回超 10 万行，仍会退化为嵌套循环——此时强制加LIMIT或拆分批次更稳
MySQL 大表 JOIN 嵌套查询 OOM 的绕过姿势
当主表和子查询结果都超 50 万行，JOIN 也可能因 join_buffer_size 不足导致磁盘临时表甚至被 kill。这不是调大内存就能解决的事。
- 手动分页驱动：用
SELECT id FROM large_table ORDER BY id LIMIT 10000 OFFSET 0拆成 100 批，每批再JOIN，比单次扫全表更可控 - 禁用 Block Nested-Loop（BNL）：在会话级执行
SET SESSION optimizer_switch='block_nested_loop=off';，逼优化器选更省内存的 Index Nested-Loop - 检查
join_buffer_size实际生效值：用SHOW VARIABLES LIKE 'join_buffer_size';确认，很多云数据库默认仅 256KB，远低于本地开发环境 - 别依赖
STRAIGHT_JOIN强制顺序：它可能让小表驱动大表，反而放大扫描量；先用EXPLAIN FORMAT=TREE看实际驱动顺序
PostgreSQL 中 EXISTS 比 IN 更省内存的真相
EXISTS 在大多数场景下确实比 IN (subquery) 内存友好，但它不是银弹——关键看子查询是否能尽早退出。
- 子查询必须带关联条件：写成
EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.created_at > '2024-01-01')，否则退化为半连接，照样物化 - 避免在
EXISTS子查询里用ORDER BY或LIMIT：PG 无法优化掉排序，会多做无用工作 - 如果子查询涉及多个表，确认最外层关联列有索引：比如
u.id在users表是主键没问题，但若用u.code关联，就得单独建索引 - 注意
NULL行影响：若子查询可能返回NULL，EXISTS不受影响，但IN遇到NULL整体判为UNKNOWN，逻辑可能意外偏移
临时表 + 分区键预过滤是真正扛量的底线方案
当嵌套逻辑复杂、又没法改业务模型时，硬扛不如主动卸载。把子查询结果落地为带索引的临时表，是最可控的大数据量处理方式。
- MySQL：用
CREATE TEMPORARY TABLE temp_ids AS SELECT DISTINCT user_id FROM events WHERE dt >= '2024-06-01';，再对temp_ids加INDEX(user_id) - PostgreSQL：优先用
CREATE UNLOGGED TABLE，避免 WAL 开销；记得后续ANALYZE，否则优化器可能误判行数 - 别省略
DISTINCT：即使业务保证唯一，也加上——防止重复值放大 JOIN 结果集，引发笛卡尔积式内存暴涨 - 临时表生命周期要明确：MySQL 临时表会话结束自动删，PG 的
UNLOGGED表需手动DROP，漏删可能占满pg_temp空间
嵌套查询的内存压力，本质是优化器对中间结果规模的误判。所有“绕过”手段，核心都是把不可控的自动物化，换成开发者可预期、可索引、可分片的显式结构。越晚做这一步，排查时看到的 Using temporary; Using filesort 就越刺眼。
