Using temporary是索引未覆盖WHERE、GROUP BY及SELECT非聚合字段导致的必然结果，需建顺序匹配的覆盖索引（如INDEX(status, category)），而非调参；sort_buffer_size对GROUP BY无效，tmp_table_size与max_heap_table_size仅防落盘。
临时表不是流程问题，是索引没对上导致的必然结果——别调参数，先看索引是否覆盖 WHERE、GROUP BY 和 SELECT 非聚合字段。
EXPLAIN 出现 Using temporary 怎么办
这表示 MySQL 正在建内存或磁盘临时表做分组，性能拐点已到。它和数据量大小无关，只和索引能否支撑「顺序读取+天然分组」有关。
- 检查
EXTRA列是否含Using temporary，一旦出现，说明优化器放弃索引直扫，转为全表捞数据再归并 - 常见误判：改了
sort_buffer_size没用——它只影响排序，不控制临时表生成；真正管临时表的是tmp_table_size和max_heap_table_size，但调大只是防落盘，不能消除临时表 - 真正要盯的是
key字段是否命中索引，以及type是否为ref或range；type = ALL就等于没走索引
GROUP BY 索引必须按顺序建，不能乱
索引列顺序必须严格匹配 GROUP BY 字段顺序，且 WHERE 中的等值条件（=、IN）可前置，范围条件（>、BETWEEN）会中断最左前缀。
- 例如
GROUP BY a, b→ 索引必须是(a, b)，写成(b, a)或(a, c, b)都无效 - 带 WHERE 时：
WHERE status = 1 GROUP BY category→ 索引应为(status, category)，不是(category)单列索引 - 如果 SELECT 中有非聚合字段（如
SELECT category, name, COUNT(*)），name必须包含在索引中且靠左，否则仍需回表，可能触发Using temporary
为什么松散索引扫描（Loose Index Scan）快
它利用 BTREE 索引天然有序的特性，只读取每个分组的第一个键值，跳过中间重复项，大幅减少 I/O。
- 前提：GROUP BY 字段是索引最左前缀，且无范围 WHERE 条件干扰（如
WHERE created_at > '2024-01-01'会让松散扫描退化为紧凑扫描） - 示例：索引
(user_id, created_at)，查询SELECT user_id, COUNT(*) FROM orders GROUP BY user_id可走松散扫描；但加了WHERE created_at > '2024-01-01'就只能走紧凑扫描，需遍历所有满足时间条件的行 - 函数用在 GROUP BY 上（如
GROUP BY DATE(created_at)）直接废掉整个索引，强制走临时表
SELECT * 或多余字段会让 GROUP BY 变慢
MySQL 无法从索引中直接拿到所有列时，必须先分组再回表取数据，极大增加内存与 I/O 压力。
-
SELECT *是 GROUP BY 查询最大陷阱——哪怕索引存在，只要没覆盖所有列，就可能放弃索引或触发临时表 - 开启
sql_mode=ONLY_FULL_GROUP_BY（默认）时，SELECT dept_id, name, COUNT(*) GROUP BY dept_id会报错；关掉虽能运行，但name值不可控 - 真要取分组内某条记录的字段（如“每个部门最早入职员工姓名”），改用
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY hire_date)（MySQL 8.0+），别硬塞进 GROUP BY
最容易被忽略的一点：GROUP BY 字段基数太高（比如按秒级时间戳分组）时，即使索引完美，临时表也会膨胀得极快——这时候该想的不是调参，而是预聚合或改用时间窗口切片。
