Using temporary表示MySQL需建内部临时表完成分组、去重或排序；真正危险的是临时表落磁盘，触发Created_tmp_disk_tables计数上涨、I/O飙升、响应变慢。
EXPLAIN里出现Using temporary说明什么
它不是报错，而是MySQL明确告诉你：当前查询必须建内部临时表才能完成分组、去重或排序。真正危险的不是“用了临时表”，而是它落到磁盘——一旦超出tmp_table_size和max_heap_table_size中较小的那个值，就会触发Created_tmp_disk_tables计数上涨，I/O飙升、响应变慢。
GROUP BY和ORDER BY字段顺序不匹配索引就必出临时表
索引不是“字段凑齐就行”，而是严格按定义顺序生效。比如查询写成GROUP BY user_id, status ORDER BY status, created_at，那索引必须是(user_id, status, created_at)——user_id是GROUP BY最左字段，status紧接其后且顺序一致，created_at再往后承接ORDER BY。
- 若建了
(status, user_id, created_at)，但GROUP BY是user_id, status，索引无法覆盖分组，照样用临时表 - MySQL 8.0+才支持混合ASC/DESC索引；5.7及更早版本建了
(a ASC, b DESC)，但查询写ORDER BY a ASC, b DESC也会退化为临时表 - 用
EXPLAIN FORMAT=TREE确认是否真免临时表：输出里不含"using_temporary_table": true才算过关
WHERE条件写法不当直接废掉索引排序能力
哪怕created_at有单列索引，只要WHERE里写了is_delete != 1或DATE(created_at) = '2024-01-01'，索引就无法用于后续ORDER BY或GROUP BY，必然触发临时表。
-
!=、NOT IN、函数包裹（如UPPER(name)）会让等值条件失效，改用范围或存在性判断：比如is_delete = 0替代!= 1 - 对时间字段做函数操作，优先改写为范围查询：
WHERE created_at >= '2024-01-01' AND created_at - JOIN条件类型不一致（如VARCHAR字段用INT值去ON）会隐式转换，导致索引失效+临时表
UNION和DISTINCT滥用也会悄悄拉临时表下水
UNION各分支对应列的类型、长度必须完全一致。一处是VARCHAR(50)，另一处是VARCHAR(100)，MySQL就得建临时表统一结构；DISTINCT没走索引时，默认走临时表去重。
- 能用
UNION ALL就别用UNION——前者不去重、不建表 -
SELECT DISTINCT user_id FROM orders WHERE status = 'paid'，如果(status, user_id)有联合索引，就能跳过临时表 - 避免
SELECT DISTINCT *，只选真正需要的字段，减少临时表数据体积
Using temporary就稳稳坐在EXPLAIN里不动；而参数调大只是延缓落盘，不是消灭问题。最容易被忽略的是字符集校对规则不一致——哪怕字段名、顺序、类型全对，utf8mb4_0900_as_cs和utf8mb4_general_ci混用，索引照样无法用于排序。 
