根本原因是JOIN后无法走索引的排序、分组或去重操作，如ORDER BY字段不在驱动表索引上或GROUP BY涉及多表字段，导致MySQL被迫写磁盘临时表。
为什么MySQL会为JOIN创建大量临时表
根本原因不是JOIN本身，而是JOIN后无法走索引的排序、分组或去重操作。比如 ORDER BY 字段不在驱动表上，或 GROUP BY 涉及多表字段，MySQL就不得不把中间结果写入磁盘临时表——尤其是当 tmp_table_size 和 max_heap_table_size 设置偏小，或者结果集含 TEXT/BLOB 列时，直接降级到 MyISAM 临时表。
常见错误现象：SHOW PROCESSLIST 中看到大量 Copying to tmp table 状态；EXPLAIN 的 Extra 列出现 Using temporary（哪怕没 Using filesort）；慢查询日志里 Rows_examined 远大于 Rows_sent。
- 检查执行计划：重点看
type是否为ALL或index，key是否为NULL - 确认
ORDER BY字段是否落在驱动表（通常是EXPLAIN中id最小的那张表）的索引最左前缀上 - 避免在 JOIN 后对非驱动表字段做
GROUP BY或DISTINCT，这几乎必然触发临时表
用STRAIGHT_JOIN强制驱动表顺序
MySQL优化器有时会选错驱动表，尤其当统计信息不准或小表数据量突增时。一旦被驱动表没有合适索引，就会把大表全扫一遍再拼接，中间结果爆炸式膨胀，临时表避无可避。
使用场景：你明确知道哪张表过滤性最强（比如带高选择率 WHERE 条件），且它与其他表的关联字段上有索引。
- 把高过滤性表放在
FROM后第一位，并用STRAIGHT_JOIN告诉优化器“别猜了，就按这个顺序” - 配合
FORCE INDEX确保关联走索引，例如：SELECT /*+ STRAIGHT_JOIN */ ... FROM orders FORCE INDEX (idx_user_status) JOIN users ON orders.user_id = users.id - 注意：如果强制顺序反而让大表变驱动表，性能会更差——务必先
EXPLAIN验证
拆JOIN：用应用层两次查询替代一次多表JOIN
当JOIN涉及三张以上表，或其中一张表数据量极大（如日志表）、又无法加有效索引时，硬扛JOIN只会让临时表更大、锁更久、OOM风险更高。此时拆成2次查询，用内存合并，往往更稳更快。
适用条件：被驱动表能通过主键或唯一索引快速定位（即第二次查询是点查），且总数据量可控（比如最终结果
- 第一次查核心表（如
orders），拿到关键ID列表：SELECT id, user_id FROM orders WHERE status = 'paid' LIMIT 100 - 用这些
user_id批量查users表：SELECT id, name FROM users WHERE id IN (1,5,8,...)（注意控制IN列表长度，避免超max_allowed_packet） - 避免在应用层用循环单条查——网络延迟和连接开销会吃掉所有收益
临时表本身还能怎么压？
即使必须用临时表，也能从引擎和结构上压体积、提速度。默认的 MEMORY 引擎不支持 TEXT/BLOB，一碰到就切 MyISAM，而 MyISAM 临时表是磁盘IO大户。
- 把
SELECT列精简到最小必要集合，去掉冗余字段，尤其避免SELECT * - 用
CAST(... AS CHAR(32))替代TEXT字段参与排序/分组（前提是内容长度可控） - 调大
tmp_table_size和max_heap_table_size（需同步设置，且不能超过max_heap_table_size），但注意全局内存压力 - 如果业务允许，考虑升级到 MySQL 8.0+，其内部临时表已默认用 InnoDB，支持行格式压缩和更好的并发控制
真正卡住性能的，往往不是JOIN语法本身，而是JOIN之后那个没被索引覆盖的 ORDER BY，或者你以为“只是加个状态字段”却让优化器放弃内存临时表。盯住 EXPLAIN 里的 Extra 列，比调参管用得多。
