EXPLAIN 显示 Using temporary 说明 MySQL 创建了临时表，通常因 GROUP BY/ORDER BY 未复用索引、DISTINCT 配合非索引字段或 JOIN 中间结果过大；应建合适联合索引、优化 JOIN 顺序并定期 ANALYZE TABLE。
为什么 EXPLAIN 显示 Using temporary 就该警惕
这代表 MySQL 在执行查询时不得不创建内部临时表来完成排序、去重或连接，尤其是当结果集无法全部放入内存（tmp_table_size 和 max_heap_table_size 中的较小值）时，会自动落盘为 MyISAM 临时表，I/O 开销陡增。常见诱因包括：GROUP BY / ORDER BY 字段未走索引、多表 JOIN 无驱动表优势、SELECT DISTINCT 配合非索引字段。
GROUP BY 和 ORDER BY 必须复用同一索引
MySQL 无法同时利用两个不同索引分别服务 GROUP BY 和 ORDER BY。若语句含 GROUP BY a, b ORDER BY b DESC，必须建立联合索引 (a, b) —— 注意顺序：前导列需匹配 GROUP BY 的最左前缀，后续列支撑 ORDER BY；若 ORDER BY 含降序（MySQL 8.0+ 支持），索引定义也需显式写成 (a, b DESC)，否则仍会触发临时表。
- 错误示例：
GROUP BY user_id ORDER BY created_at DESC，但只有单列索引user_id和单独的created_at索引 → 必走临时表 - 正确做法：添加联合索引
ALTER TABLE logs ADD INDEX idx_user_created (user_id, created_at); - 注意：如果
WHERE条件用了status = 1，更优索引可能是(status, user_id, created_at)，把过滤列前置
避免 DISTINCT + 非索引字段组合
SELECT DISTINCT name, email FROM users WHERE city = 'Beijing' 若 name 或 email 无索引，MySQL 通常会先查出所有匹配行，再在内存/磁盘临时表中去重。解决路径很直接：
- 确认是否真需要
DISTINCT：业务上是否存在重复逻辑？有时是 JOIN 导致的笛卡尔积假象，应优先修复 JOIN 条件 - 如必须保留，且字段基数高（如邮箱），可考虑为常用组合建联合索引，例如
(city, name, email)，让覆盖索引直接返回结果，跳过回表和临时表 - 极端情况：用
GROUP BY name, email替代DISTINCT，两者语义等价，但优化器对GROUP BY的索引利用有时更积极（尤其配合SQL_BIG_RESULT提示时）
JOIN 时强制驱动表并控制中间结果集大小
临时表常在被驱动表（JOIN 右侧）数据量过大时生成，比如 LEFT JOIN 中右表无有效 WHERE 过滤。关键动作是：
- 用
STRAIGHT_JOIN显式指定驱动表顺序，避免优化器误判，例如SELECT ... FROM t1 STRAIGHT_JOIN t2 ON t1.id = t2.t1_id WHERE t1.status = 1 - 确保被驱动表的
ON字段有索引（通常是外键字段），且该索引能高效定位记录，而非全扫描 - 在
JOIN前用子查询或IN限制右表 ID 范围，例如先SELECT id FROM t1 WHERE status = 1，再JOIN t2 ON t2.t1_id IN (subquery)—— 但注意IN列表不宜过长，否则改用临时表 +JOIN
临时表是否生成，最终取决于优化器对中间结果集大小的预估，而这个预估高度依赖统计信息准确性。定期执行 ANALYZE TABLE 比盲目调大 tmp_table_size 更治本。
