EXPLAIN里出现Using temporary说明MySQL必须建内部临时表才能完成分组、去重或排序；真正危险的是临时表落磁盘，即超出tmp_table_size与max_heap_table_size中较小值时触发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字段顺序不匹配索引就必出临时表
索引不是“字段凑齐就行”，而是严格按定义顺序生效。比如查询写成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也会退化为临时表 -
SELECT *+GROUP BY a会强制触发临时表（违反SQL标准），必须显式聚合非分组字段，或只选需要的列
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 < '2024-01-02' - 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 *，只选真正需要的字段，减少临时表数据体积 - 子查询里有
GROUP BY，主查询EXPLAIN看不到Using temporary，得单独EXPLAIN子查询
Using temporary就稳稳坐在EXPLAIN里不动；而参数调大只是延缓落盘，不是消灭问题。最容易被忽略的是字符集校对规则不一致——哪怕字段名、类型、长度都对得上，只要COLLATION不同，索引就无法被复用。 
