GROUP BY + 多表 JOIN 卡在 Using temporary，主因是索引未覆盖全部查询路径：需同时包含 WHERE 条件、JOIN 字段、GROUP BY 列及 SELECT 中非聚合字段，缺一环即触发临时表。
SELECT 多表合计查询（比如 GROUP BY + SUM() + 多表 JOIN）卡在 Using temporary，基本就是没走覆盖索引，或者索引根本没被用上。直接加索引不等于解决问题——得让 MySQL 在执行 GROUP BY 和 JOIN 时，**只靠索引就能拿到所有需要的字段，不回表、不排序、不建临时结构**。
为什么 GROUP BY 容易触发临时表？
MySQL 的 GROUP BY 默认会尝试用索引完成分组；一旦做不到，就退化为内存/磁盘临时表。常见触发点包括：
-
GROUP BY字段没索引，或索引不是最左前缀匹配 -
SELECT的字段超出索引列范围（比如索引是(user_id, status)，但你查了user_name，就得回表） -
ORDER BY字段和GROUP BY不一致，且没共用索引 -
JOIN后的分组字段来自非驱动表（比如LEFT JOIN b ON a.id = b.a_id，却对b.status分组）
覆盖索引必须包含哪些列？
覆盖索引不是“有索引就行”，而是要满足：**索引里包含所有 GROUP BY 字段 + 所有 SELECT 中的非聚合字段 + 所有 JOIN 和 WHERE 条件字段**。
例如这个典型慢查询：
SELECT u.name, COUNT(o.id), SUM(o.amount) FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE u.dt = '2026-05-01' GROUP BY u.id, u.name;
要让它免临时表，users 表至少需要复合索引：
ALTER TABLE users ADD INDEX idx_dt_id_name (dt, id, name);
而 orders 表的关联字段 user_id 必须有索引（否则先扫 users 再全表扫 orders），建议：
ALTER TABLE orders ADD INDEX idx_user_id_amount (user_id, amount);
注意：idx_user_id_amount 把 amount 放后面，是为了让 SUM(o.amount) 能直接从索引取值，避免回表。
EXPLAIN 看什么才说明覆盖生效？
执行 EXPLAIN 后，关键看三处：
-
type是ref或range（不是ALL或index） -
key显示用了你刚建的复合索引名 -
Extra里没有Using temporary，也没有Using filesort；理想状态是出现Using index（表示纯索引扫描）
如果 Extra 出现 Using index condition，说明用了 ICP（索引条件下推），也是好信号；但若同时带 Using where，得检查 WHERE 条件是否真的能被索引覆盖。
JOIN 顺序和驱动表选错，索引白建
MySQL 用 Nested Loop Join，驱动表（外层循环）决定整体性能。如果 users 表只有几百行，orders 表有千万行，那 users 必须是驱动表。可以用 STRAIGHT_JOIN 强制：
SELECT STRAIGHT_JOIN u.name, COUNT(o.id), SUM(o.amount) FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE u.dt = '2026-05-01' GROUP BY u.id, u.name;
但更稳妥的是：用子查询提前过滤大表，再 JOIN：
SELECT u.name, COUNT(o.id), SUM(o.amount) FROM users u INNER JOIN ( SELECT user_id, amount FROM orders WHERE create_time >= '2026-05-01 00:00:00' ) o ON u.id = o.user_id WHERE u.dt = '2026-05-01' GROUP BY u.id, u.name;
此时 orders 子查询可走 create_time 索引，结果集变小，JOIN 压力骤降——即使没覆盖索引，也比硬扛全量 orders 强得多。
GROUP BY + 多表 JOIN 场景下，索引必须横跨条件过滤、连接匹配、分组依据、聚合取值四个环节，缺一不可。漏掉任意一环，MySQL 就会悄悄建临时表。 
