using filesort是性能断崖的明确信号，表明mysql未用索引排序，需额外内存或磁盘排序；常见原因包括order by字段无索引、联合索引顺序不匹配或where范围条件中断最左前缀。
Extra 列里只要出现 Using filesort 或 Using temporary，基本就可以判定这条 SQL 存在明确可优化的瓶颈，优先级高于其他字段信号。
为什么 Using filesort 是硬性红线
这不是“可能慢”，而是 MySQL 明确告诉你：它没用索引排序，得把符合条件的行全捞出来，再额外做一次内存或磁盘排序。哪怕只返回 10 行，只要 rows 是 10 万，排序开销就不可忽视。
- 常见诱因：
ORDER BY字段没索引；联合索引顺序和排序要求不匹配（比如索引是(a, b)，却写ORDER BY b）；WHERE用了范围条件后又ORDER BY非前导列 - 验证方式：执行
EXPLAIN SELECT * FROM t WHERE a > 10 ORDER BY b;，看Extra是否含Using filesort - 修复思路：给
ORDER BY字段单独建索引，或调整联合索引顺序使其覆盖WHERE + ORDER BY全路径（如改成(a, b)）
Using temporary 暴露的是逻辑层低效
临时表不是“用了就一定坏”，但出现在普通查询里，通常意味着 MySQL 被迫用低效方式实现语义——比如去重、分组、某些 JOIN 或子查询。
- 典型场景：
SELECT DISTINCT name FROM user;（name无索引）、GROUP BY字段未被索引覆盖、UNION结果集合并 - 注意陷阱：即使
type是ref、rows很小，Using temporary仍可能导致高延迟，尤其在并发下争抢内存或磁盘临时表空间 - 关键判断点：先确认是否真需要
DISTINCT或GROUP BY；若必须，就把涉及字段加进索引，优先尝试覆盖索引（避免回表触发临时表）
Using where 和 Using index 要合起来看
单独看 Using where 是中性信息（只是说明过滤发生在 Server 层），但和 type、key 搭配才有意义：
-
type = ALL+Using where：全表扫描后再过滤，大概率缺 WHERE 条件索引 -
Using index+type = ref：理想状态，索引覆盖查询所需全部字段，无需回表 -
Using index condition：索引下推（ICP）生效，MySQL 把部分WHERE条件下推到存储引擎层过滤，比纯Using where更高效，但需确保 MySQL 版本 ≥ 5.6 且引擎支持
真正容易被忽略的，是 Using filesort 和 Using temporary 同时出现——这意味着 MySQL 不仅要扫大量数据，还要反复排序+建临时表，这时候光调索引可能不够，得回头检查 SQL 逻辑是否可简化，比如用 LIMIT 限制结果集、拆分复杂 GROUP BY、或用物化视图预计算。
