临时表过大是LEFT JOIN失控的明确信号，需用EXPLAIN FORMAT=TREE确认materialize或BNL回退，检查右表连接键重复与索引缺失，确保WHERE条件下推至ON子句，并通过拆分SQL、预建索引和精简SELECT列来控制中间结果集。
临时表过大不是LEFT JOIN的副作用，而是它失控的明确信号——只要看到Copying to tmp table on disk或Created_tmp_disk_tables飙升，就说明中间结果集已经脱离控制。
用EXPLAIN FORMAT=TREE确认是否真由LEFT JOIN触发临时表
别猜，直接看执行计划里有没有materialize或hash_join回退到BNL（Block Nested-Loop）。这些关键词意味着MySQL被迫把左表结果缓存起来逐行匹配右表，一旦超出join_buffer_size，就会落盘。
- 运行
EXPLAIN FORMAT=TREE SELECT ... LEFT JOIN ...，重点找using_temporary_table: true和using_filesort: true - 对比
SHOW STATUS LIKE 'Created_tmp%'前后值，如果Created_tmp_disk_tables明显上涨，就是LEFT JOIN在写磁盘 - 注意：
Using temporary出现在Extra列里，不等于一定落盘；只有配合on disk才真正危险
检查LEFT JOIN右表连接键是否重复且无索引
膨胀和临时表往往是同一根导火索：右表连接键重复 → 匹配行数爆炸 → join_buffer撑爆 → 落盘。而索引缺失会让问题雪上加霜。
- 查右表重复键：
SELECT join_col, COUNT(*) FROM right_table GROUP BY join_col HAVING COUNT(*) > 1 - 确认右表
join_col是否有索引：SHOW INDEX FROM right_table WHERE Column_name = 'join_col' - 类型必须严格一致：比如左表是
INT，右表不能是BIGINT或VARCHAR，否则隐式转换让索引失效 - 如果右表是大宽表，但只用其中几列，优先建覆盖索引，例如
INDEX (join_col, status, updated_at)
验证WHERE条件是否错误地写在LEFT JOIN外层
这是最隐蔽也最致命的问题：把本该下推到ON里的过滤条件放在WHERE里，会导致LEFT JOIN先全量匹配再砍NULL，中间结果早已溢出。
- 错误写法：
LEFT JOIN right_table r ON l.id = r.l_id WHERE r.status = 'active'→ 实际等效INNER JOIN，且白生成大量NULL行 - 正确写法：
LEFT JOIN right_table r ON l.id = r.l_id AND r.status = 'active'→ 从源头只拉活跃记录，左表仍全量保留 - 特别注意
r.col IS NOT NULL这类判断，也会让LEFT JOIN语义退化，应改用COALESCE(r.col, '') != ''之类安全写法 - 多表LEFT JOIN时，每个
ON都要独立检查条件归属，不能默认“都归右边”
临时表已生成，怎么快速定位哪一步撑爆了内存？
不要一上来就调tmp_table_size，先缩小怀疑范围。临时表膨胀通常发生在JOIN之后的GROUP BY、ORDER BY或DISTINCT阶段，而不是JOIN本身。
- 把原SQL拆成两段：先
CREATE TEMPORARY TABLE tmp AS SELECT ... LEFT JOIN ...，再对tmp做GROUP BY或ORDER BY，分别看哪步触发Copying to tmp table on disk - 对临时表立刻建索引：
ALTER TABLE tmp ADD INDEX idx_join_key (join_key)，再跑后续操作 - 如果
ORDER BY字段没索引，且数据量大，考虑加LIMIT前先用子查询收敛结果集，例如(SELECT * FROM tmp ORDER BY x DESC LIMIT 1000) AS limited - 避免在LEFT JOIN后直接
SELECT *，只选真正需要的列——宽表JOIN后字段越多，临时表体积指数增长
真正难处理的从来不是“怎么调大临时空间”，而是当EXPLAIN显示rows列突然从1万跳到800万时，你得立刻意识到：不是磁盘不够，是ON条件漏了关键字段，或者右表根本没走索引——这时候改SQL比改配置快十倍。
