JOIN性能问题90%源于执行计划错误，应先用EXPLAIN ANALYZE检查索引使用、行数估算偏差及临时表/缓冲区提示，再针对性优化索引、分片或物化中间结果。
JOIN导致查询超时或OOM，先看执行计划是否走错索引
千万级表JOIN慢，90%不是语法问题，而是优化器选了全表扫描+嵌套循环。别急着改SQL，先用 EXPLAIN ANALYZE 看真实执行路径——尤其注意rows预估是否严重偏离实际、Extra里有没有Using join buffer或Using temporary。
- 如果驱动表没走索引，优先给JOIN条件字段加复合索引（顺序按ON子句中出现顺序）
- 避免在JOIN条件里对字段做函数操作，比如
ON DATE(t1.created_at) = DATE(t2.date)会直接让索引失效 - MySQL 8.0+ 可临时启用
SET optimizer_switch='block_nested_loop=off'测试是否因BNL算法放大内存开销
大表JOIN结果集过大，拆成主键范围分片查询更可控
一次性JOIN两千万行，即使有索引，网络传输、内存聚合、排序缓冲都可能崩。不如把大JOIN“切片”：先查小表（或驱动表）的主键范围，再分批JOIN，最后UNION ALL汇总。
- 示例：用
SELECT id FROM orders WHERE status = 'paid' ORDER BY id LIMIT 10000 OFFSET 0拿一批ID，再JOIN ... WHERE o.id IN (1,2,...) - OFFSET越大越慢，改用游标式分页：
WHERE id > ? AND status = 'paid' ORDER BY id LIMIT 10000 - 分片大小建议5k–50k行，太小IO压力大，太大仍可能OOM；用
SHOW PROCESSLIST观察每批次耗时是否陡增
LEFT JOIN变INNER JOIN后性能飙升？检查NULL值处理逻辑是否被误删
有些场景把LEFT JOIN改成INNER JOIN快十倍，但往往是因为WHERE里写了t2.col IS NOT NULL，悄悄把外连接转成了内连接——这不一定是bug，但必须确认业务是否允许丢弃左表无匹配的记录。
- 检查WHERE条件是否隐含非空约束，例如
WHERE t2.amount > 100也会过滤掉t2为NULL的行 - 若业务真需要保留左表全部数据，又嫌LEFT JOIN慢，可考虑先用
SELECT id FROM t2 WHERE ...建临时表并加索引，再与主表JOIN - PostgreSQL用户注意：
LEFT JOIN LATERAL在某些关联子查询场景下比传统LEFT JOIN更易控制执行顺序
汇总阶段卡在GROUP BY或ORDER BY，优先物化中间结果
JOIN完再GROUP BY千万行，排序和哈希聚合极易撑爆work_mem（PostgreSQL）或sort_buffer_size（MySQL）。与其硬扛，不如把JOIN结果存到临时表，加好索引再聚合。
- MySQL：用
CREATE TEMPORARY TABLE tmp_join AS SELECT ... JOIN ...，然后ALTER TABLE tmp_join ADD INDEX idx_group (user_id, status) - PostgreSQL：用
CREATE UNLOGGED TABLE+CLUSTER ON按分组字段物理排序，GROUP BY速度常提升3–5倍 - 别依赖
SELECT ... INTO TEMP自动建表——字段类型可能被推断错误（比如把bigint当int），显式定义更稳
真正难的不是拆查询，而是判断哪一层该拆：是JOIN前筛数据，还是JOIN后分组，抑或把JOIN本身变成应用层双遍历。这些决策点藏在执行计划的rows估算偏差、Buffers读取量、以及慢日志里的Query_time和Rows_examined比值里——盯住它们，比调参有用得多。
