distinct触发using temporary的根本原因是无法利用索引有序性“流式跳重”，只能全量扫描后排序或哈希去重；需建连续最左前缀联合索引并配合等值where条件，才可能避免临时表。
能避免临时表，就别让它出现——DISTINCT 触发 Using temporary 的根本原因是 MySQL 没法靠索引顺序“跳着读”，只能把所有行拉进来硬去重。
为什么 DISTINCT 一定会建临时表？
MySQL 对 DISTINCT 的默认实现是 Sort-Based：先全量扫描匹配行，再排序、相邻去重。只要没索引支撑这个“顺序跳重”逻辑，就必然走临时表。典型表现是 EXPLAIN 中 Extra 字段出现 Using temporary; Using filesort。
注意：Using temporary 不代表一定写磁盘，但哪怕在内存里建哈希表，也会显著增加 CPU 和内存压力，尤其在并发高或字段多时。
- 单列
DISTINCT a有INDEX(a)→ 可能跳过临时表（若满足松散索引扫描条件） - 多列
DISTINCT a, b有INDEX(a, b)→ 能避免回表，但仍大概率触发临时表，因为 MySQL 无法对多列组合做“松散跳” -
DISTINCT a却只建了INDEX(b, a)→ 索引失效，必走临时表
怎么让 DISTINCT 不建临时表？
核心是让优化器能用索引完成“流式去重”：遍历索引项时，只要当前值和上一个不同，就直接取，不缓存整行。这需要同时满足：
-
DISTINCT字段必须是某个复合索引的连续最左前缀，例如DISTINCT dept需要INDEX(dept, city)，不能是INDEX(city, dept) - 如果有
WHERE条件，只能作用于该索引中更左的前缀列，且必须是等值条件，比如WHERE dept = 'tech'；若写成WHERE city = 'bj'或WHERE dept > 'a'，松散扫描就失效 -
EXPLAIN中看到Extra: Using index for group-by才算真正启用松散索引扫描（别被字段名误导，它也用于DISTINCT）
多列 DISTINCT 临时表绕不开？试试 GROUP BY
MySQL 对 GROUP BY 的索引优化路径更成熟，尤其在 5.7+ 版本中，SELECT a, b FROM t GROUP BY a, b 有时比 SELECT DISTINCT a, b FROM t 更容易触发松散逻辑（尽管语义等价）。实操建议：
- 先确保有覆盖索引
INDEX(a, b)（或带WHERE条件时为INDEX(c, a, b)） - 跑
EXPLAIN对比两者的Extra字段：谁没有Using temporary就选谁 - 如果后续要加
COUNT(*)或HAVING，直接用GROUP BY更自然，不用二次改写
覆盖索引能省回表，但救不了临时表
覆盖索引（如对 SELECT DISTINCT user_id FROM t WHERE status = 1 建 INDEX(status, user_id)）能让 MySQL 完全不访问数据行，极大降低 I/O，但它不能消除临时表——去重判断本身仍需中间结构。
真正卡住性能的，往往不是 DISTINCT 关键字，而是它暴露了索引缺失、字段顺序错位、或 WHERE 条件写法破坏了索引可下推性。每次加索引前，先用 EXPLAIN 看清执行路径，比盲目堆索引更有效。
