MySQL EXPLAIN ANALYZE 怎样看排序是否落盘

想判断 MySQL 的排序是不是“落盘”，不要只看普通 EXPLAIN 里有没有 Using filesort。更可靠的做法是先用 EXPLAIN ANALYZE 找到实际执行树里的排序节点，再在同一个会话中读取状态变量的变化。

结论：EXPLAIN ANALYZE 能告诉你排序节点的估算行数、实际行数、耗时和循环次数，但它不会直接给出一个“Sort 已落盘”的布尔字段。Created_tmp_disk_tables 的增量是磁盘临时表线索，Sort_merge_passes 的增量说明排序发生了归并过程；两者要和执行树一起解释。

把判断拆成两层：执行树回答“哪里在排序、实际代价多大”，会话状态回答“这次执行是否创建了磁盘临时表或产生了归并”。

先用 EXPLAIN ANALYZE 找到排序节点

先把问题查询限制为可重复的 SELECT，再用 FORMAT=TREE 查看执行树。MySQL 8.4 的 EXPLAIN ANALYZE 会实际执行语句，并以 TREE 形式展示每个迭代器的估算成本、估算行数、首行时间、实际耗时、实际行数和循环次数。

EXPLAIN ANALYZE FORMAT=TREE
SELECT order_id, customer_id, created_at, total_amount
FROM orders
WHERE created_at >= '2026-10-01'
ORDER BY total_amount DESC
LIMIT 100;
-- EXPLAIN ANALYZE 会真正执行 SELECT；先确认查询只读且 LIMIT、过滤条件符合排查场景。
-- FORMAT=TREE 让 Sort、Filter、Table scan 等迭代器关系更容易阅读。

输出中如果出现 Sort: 或带排序语义的迭代器，说明这条执行路径确实包含排序。先记录排序节点附近的 cost、rows、actual time、rows 和 loops。例如，估算只有几百行而实际进入排序的行数达到几十万，通常比单看“有没有排序”更值得继续追查。

不要把 Sort 节点直接等同于磁盘落盘

排序节点只说明执行计划需要排序，并不能单独证明排序数据已经写入磁盘。排序可能在内存中完成，也可能因为中间结果、临时表或多路归并产生磁盘相关开销。actual time 变大是性能线索，但不是存储介质证明；并发、缓存和数据分布也会改变耗时。

可以先做一个简单的对照表：

在同一会话读取磁盘临时表和归并计数

为了减少其它连接的噪声，最好在专用会话中观察 SESSION 状态，并在目标查询前后比较数值。下面的写法先清零当前会话的计数，再执行查询，最后一次性读取与临时表和排序有关的变量：

FLUSH STATUS;

EXPLAIN ANALYZE FORMAT=TREE
SELECT order_id, customer_id, created_at, total_amount
FROM orders
WHERE created_at >= '2026-10-01'
ORDER BY total_amount DESC
LIMIT 100;

SHOW SESSION STATUS
WHERE Variable_name IN (
    'Created_tmp_tables',
    'Created_tmp_disk_tables',
    'Sort_merge_passes',
    'Sort_rows',
    'Sort_scan',
    'Sort_range'
);
-- FLUSH STATUS 只作用于当前会话的状态计数，便于把结果归因到这次排查。
-- Created_tmp_disk_tables 增长是磁盘临时表线索，Sort_merge_passes 增长是归并线索。
-- SHOW SESSION STATUS 本身会使用内部临时表，Created_tmp_tables 可能包含这一步的开销。

如果 Created_tmp_disk_tables 大于零，说明这次会话创建过内部磁盘临时表；但它是语句级计数，不能单凭这个数断言“排序就是唯一原因”。如果 Sort_merge_passes 大于零，说明排序算法发生了归并轮次，通常值得结合 sort_buffer_size、排序行数和查询形状继续分析。

Created_tmp_tables 与 Created_tmp_disk_tables 应一起看：前者是内部临时表总数，后者是其中的磁盘临时表数量。MySQL 文档还提示，某些以内存映射文件承载的临时表不计入 Created_tmp_disk_tables，所以它适合作为强线索，而不是覆盖所有实现路径的绝对证明。

最后按证据强弱判断是否需要优化

建议按下面的顺序收敛结论：

1. 先确认 TREE 输出里确实有排序节点，并记录实际输入行数和耗时。
2. 再看当前会话的 Created_tmp_disk_tables 是否增长；增长说明出现了磁盘临时表，但还要结合语句是否包含分组、去重或其它中间结果。
3. 再看 Sort_merge_passes、Sort_rows 与 actual rows 是否同方向增长，用来判断排序规模和归并压力。
4. 最后才回到索引、排序列顺序、过滤条件和数据分布讨论改写方案；不要因为看到 Using filesort 就直接增加索引。

还要注意 EXPLAIN ANALYZE 会执行语句。对只读查询可以在低风险环境中使用；对写入语句不要把它当成普通计划查看命令。若需要观察生产问题，应使用脱敏数据、只读副本或经过审批的同会话采样，避免为了取证改变业务负载。

常见问题

看到 Sort 节点就说明排序落盘了吗？

不是。Sort 节点只说明执行路径需要排序。要判断是否出现磁盘临时表，应结合同一会话的 Created_tmp_disk_tables；要判断是否发生排序归并，还要看 Sort_merge_passes。

为什么 Created_tmp_disk_tables 没增长，但查询仍然很慢？

慢不一定来自磁盘临时表，可能是排序输入行数过大、扫描范围过宽、并发竞争或缓存状态变化。回到 EXPLAIN ANALYZE 的实际行数和各迭代器耗时，不要把一个状态变量当成完整性能剖析。

EXPLAIN ANALYZE 能替代普通 EXPLAIN 吗？

不能完全替代。它会实际执行并给出运行时指标，适合验证估算与实际的偏差；普通 EXPLAIN 更适合低成本查看优化器计划。选择哪一个，要看查询是否可安全执行。

因此，MySQL EXPLAIN ANALYZE 判断排序落盘的关键不是寻找一个神奇字段，而是把执行树与同会话状态计数拼成一条证据链：先定位排序，再确认实际规模，最后用磁盘临时表和归并计数补足存储路径判断。