mysql 获取执行计划（面试官MySQL执行计划Using）

mysql 获取执行计划（面试官MySQL执行计划Using）执行过程where后的dept有索引，但name无索引order by 字段（有索引）本来就是有序的，所以无需另外排序例子根据ID主键排序，执行计划无Using filesort但现实开发中，你字段有索引有时也会出现Using filesort

MySQL、数据库、MySQL性能优化、程序员、DBA

MySQL版本

mysql版本不同，有些特性是有区别的，请小白注意

数据准备

一张员工工资表，字段很简单

Using filesort

1. using filesort一般出现在 order by 这样的SQL执行计划
2. using filesort出现了，不一定会导致MySQL性能问题，出现大量数据需要using filesort会导致性能瓶颈

MySQL排序分2类

1. 有索引(扫描索引生成有序结果)
2. 无索引（内存中排序）

有索引情况

order by 字段（有索引）本来就是有序的，所以无需另外排序

例子根据ID主键排序，执行计划无Using filesort

但现实开发中，你字段有索引有时也会出现Using filesort

有索引也分3种场景

1. 索引只出现where
2. 索引只出现order by
3. 索引出现在where和order by

场景1：索引只出现where

where后的dept有索引，但name无索引

执行过程

1：先通过索引字段dept匹配出满足where条件的主键ID（B 树节点找叶子节点，时间复杂度0（logN））

2：然后通过这些主键ID找到这几行数据(时间复杂度0（M*logN），M临时表rows)

3：对这些数据进行filesort排序工作（时间复杂度0（M*logM） M临时表的rows）

本例子中where匹配数据非常少，所以整个执行过程消耗几乎0秒，

当你的生产代码where匹配出非常多数据时，filesort执行就会非常耗时了

场景2 索引只在order by

索引只出现在order by 也就是索引扫描排序了

我通过FORCE INDEX强制执行索引index_dept

这里我不强制，MySQL可能会filesort 因为当数据量非常少情况时，filesort更加快些。

这里当数据量够大是，执行时间会非常耗时。

整个时间复杂度是0（M*logN ） M主键id总数量，N索引叶子节点个数

场景3索引同时在where和order by

这是最佳场景，你的业务SQL最好是这样设计，这样省去了回查表操作

无索引情况

order by 字段（无索引），所以需要对结果进行排序操作

执行计划会出现Using filesort

例子根据姓名排序，此字段无索引

优化思路

• 老套路，合理的去创建索引
• Using filesort是通过相应的排序算法 将取得的数据在内存中进行排序。
• 避免多余的排序，很多业务无需排序可以直接order by Nulll来禁止排序
• 请看场景3，就是最佳方案

以上皆为个人理解，如果有理解错的地方，欢迎专家指出