Using temporary出现是因为索引未覆盖WHERE条件、GROUP BY字段及SELECT非聚合字段三环节，导致MySQL被迫建临时表归组；必须按执行顺序创建联合索引（如INDEX(status, user_id)）才能消除。
GROUP BY 为什么总出现 Using temporary
看到 Using temporary 就说明 MySQL 正在建内存或磁盘临时表来归组，这不是数据量大才出的问题，而是索引没对上执行逻辑。它常和 Using filesort 一起出现，意味着既要落表又要排序，I/O 开销陡增。
根本原因不是“没索引”，而是索引无法支撑三个环节同时完成：WHERE 过滤、GROUP BY 分组、SELECT 中的非聚合字段读取。只要其中任一环节脱节，MySQL 就退化为全表扫描 → 写临时表 → 排序 → 聚合。
常见错觉是建了单列索引就完事，比如 GROUP BY user_id 却只建了 INDEX(created_at)；或者 WHERE 用了函数，如 WHERE YEAR(created_at) = 2026，直接让所有索引失效。
怎么建索引才能真正跳过临时表
核心是让一个联合索引覆盖 WHERE 条件、GROUP BY 字段、SELECT 非聚合字段三者，并严格按执行顺序排列：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
WHERE status = 'paid' GROUP BY user_id→ 必须建INDEX(status, user_id)，不能是INDEX(user_id, status)或单独的INDEX(user_id) -
GROUP BY dept, role→ 索引必须是(dept, role)，反过来无效 -
SELECT user_id, COUNT(*), MAX(amount) FROM t WHERE status = 1 GROUP BY user_id→ 最优索引是INDEX(status, user_id, amount)，因为MAX(amount)要求amount紧接在分组字段后才能触发 Loose Index Scan - 如果 SELECT 里有
name，而name不在索引中，即使user_id有索引，也会因回表触发临时表；应扩展为INDEX(status, user_id, name)
哪些写法会悄悄强制用临时表
有些语句表面简单，但语义上绕不开临时表，EXPLAIN 还不一定报出来：
-
SELECT DISTINCT a, b FROM t WHERE c = 1→ 和GROUP BY等价，索引必须是INDEX(c, a, b)，不是INDEX(a, b) -
UNION默认等价于UNION DISTINCT，哪怕子查询结果天然不重叠，也会合并去重；优先用UNION ALL -
SELECT user_id, MAX(price), city FROM t GROUP BY user_id→city不在 GROUP BY 中，且未聚合，MySQL 会报错（ONLY_FULL_GROUP_BY模式下）或返回不确定值，此时无论如何建索引都绕不开临时表 -
SQL_BUFFER_RESULT会强制生成临时表，即使索引完备也要检查是否被 ORM 或客户端无意启用
ORDER BY NULL 和参数调优的真实作用
ORDER BY NULL 不是可选项，是必要指令。MySQL 5.7+ 已移除 GROUP BY 隐式排序语义，但优化器仍可能因“以为你要排序”而选错路径。加上它，才能明确关闭无谓排序步骤。
tmp_table_size 和 max_heap_table_size 只控制临时表是否落盘，不解决“要不要建临时表”的问题：
- 两个值必须设成一致，否则无效；默认 16MB，生产建议同步设为
67108864（64MB）到268435456（256MB） - 该设置对已建立连接无效，只影响新连接
- 必须监控
Created_tmp_disk_tables / Created_tmp_tables比值，持续高于 5% 就说明仍在频繁落盘 -
sort_buffer_size对 GROUP BY 完全无效，调它既不减少临时表，也不加速分组，高并发下还容易 OOM
真正卡住性能的，往往是索引列顺序错了一位、WHERE 里多套了一个函数、或者 SELECT 多写了一个没被覆盖的字段——这些细节比调参重要得多。
