MySQL EXPLAIN ANALYZE 如何观察临时表和排序开销

MySQL 慢查询里出现临时表或排序，并不等于一定要立刻加索引。更可靠的判断方式是先用只读语句运行 EXPLAIN ANALYZE FORMAT=TREE，看每个节点的 actual time、rows 和 loops，再把耗时最高的节点和传统执行计划中的 Using temporary、Using filesort 对上。

EXPLAIN ANALYZE 先看哪几项

假设有一张订单表，需要统计某个月各门店的已支付金额，并按汇总金额取前 20 名：

EXPLAIN ANALYZE FORMAT=TREE
SELECT shop_id, DATE(created_at) AS order_day, SUM(amount) AS total_amount
FROM orders
WHERE status = 'paid'
  AND created_at >= '2026-08-01'
  AND created_at 

树形输出中的 actual time=0.120..18.640 rows=20 loops=1 可以这样读：节点产出第一行和最后一行的大致时间、实际行数，以及被重复执行的次数。优先关注耗时大的节点和行数突然膨胀的节点；估算值与实际值差距很大时，先怀疑统计信息或过滤条件，而不是马上改参数。

把临时表和排序开销定位到具体节点

这类 SQL 常见的树形结构可以抽象为“订单扫描与过滤 → 使用临时表聚合 → 对聚合结果排序 → LIMIT”。这里的临时表承接分组结果，排序节点再处理汇总后的结果集。不要只因为看到了临时表就判定查询慢：如果上游只传入很少的行，临时表本身可能不是主要成本；反过来，排序前的实际行数很大，即使最终只返回 20 行，也可能成为瓶颈。

可以同时看传统格式：

EXPLAIN
SELECT shop_id, DATE(created_at) AS order_day, SUM(amount) AS total_amount
FROM orders
WHERE status = 'paid'
  AND created_at >= '2026-08-01' AND created_at 

Extra 中的 Using temporary 表示需要临时表保存结果，Using filesort 表示需要额外排序过程。JSON 格式则关注 using_temporary_table 和 using_filesort。这些字段回答“计划是否需要这类操作”，而 EXPLAIN ANALYZE 回答“这次执行在对应节点花了多少时间”。

根据节点结果决定改 SQL 还是改索引

如果高耗时出现在扫描或过滤之前，先检查 WHERE 条件是否足够收窄，并考虑围绕等值条件和时间范围设计复合索引，例如让 status、created_at 参与访问路径。但这个索引未必能消除按表达式分组和按聚合值排序，因为 DATE(created_at) 与 SUM(amount) 都发生在扫描之后。

如果高耗时集中在聚合后的 Sort，重点是减少进入聚合的行数、确认是否真的需要按汇总值倒序，或把报表统计改为合适的汇总表。不要为了消除一个标记而盲目添加索引：每次只改一个条件或索引，然后用同一条分析语句比较 actual time、rows、loops，并确认结果集仍然正确。

常见问题

看到 Using filesort 就一定要加索引吗？

不一定。它只是说明需要额外排序；当输入行数很少或排序本身很快时，强行加索引可能增加写入成本。先看 Sort 节点的实际时间。

EXPLAIN ANALYZE 为什么不能当作普通 EXPLAIN？

因为它会执行查询并返回实际运行统计。对只读、可控范围的 SELECT 使用，生产大查询应先缩小时间范围并评估执行影响。

为什么 LIMIT 20 仍然可能排序很慢？

如果排序字段是聚合结果，MySQL 通常要先得到足够的分组结果才能决定前 20 名，LIMIT 只限制最终输出，不必然限制前面的聚合与排序工作。