临时表过大是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比改配置快十倍。