对结果进行排序操作的代价可能很高，因此可以通过避免排序或让参与排序的数据行更少来优化查询性能。
当 MySQL 不能使用索引产生有序结果时，它必须对数据行进行排序。这有可能是在内存中进行也可能是在磁盘进行，但 MySQL 始终将这个过程称之为 filesort，即便实际上并没有使用一个文件。
如果用于排序的值可以一次性放入排序缓存中，MySQL 可以在内存中使用快排算法进行排序。如果 MySQL 不能在内存中进行排序，则会在磁盘中按块逐块排序。它对每个块使用快排算法，然后在将这些排序好的块合并到结果中。
有两个文件排序（filesort）算法：
- 两次遍历（Two passes，旧的算法）：读取ORDER BY 指定列对应的数据行指针，然后对其进行排序，再遍历已排序的列表并重新读取输出需要的数据行。由于从数据表读取了两次数据行，因此两次遍历算法的代价可能非常高。而且第二次读取会导致很多的随机 I/O 访问，这对 MyISAM 引擎（由于 MyISAM 依靠操作系统缓存保存数据，他使用系统调用获取每一行）的性能影响尤其大。另一方面，在排序过程中存储最少的数据量，因此如果要排序的数据行都在内存中，则对于存储更少数据和二次读取最终结果的数据行的情况来说，代价就会更低。
- 单次遍历：读取需要查询的所有列，然后依据 ORDER BY指定的列进行排序，再遍历排序好的列表并输出指定的数据列。这个算法在 MySQL 4.1及更高的版本才支持。由于它避免了数据表行的二次读取以及将更多的随机 I/O 转换为顺序 I/O，因此这种方式性能更高，尤其是对于 I/O 跨度大的数据集查询而言。然而，这样意味着它可能占据更多的内存空间，这是因为它保存了每个数据行需要读取的列，而不仅仅是需要排序的列。这意味着对于排序缓冲区来说，利用率更低，而且文件排序需要处理更多的排序合并。
很难说哪种算法更有效，对每个算法来说都会有最优和最坏案例。MySQL 在数据表全部列加上用于排序的列的大小不超过 max_length_for_sort_data 时会使用单次遍历算法。可以通过修改这个参数影响排序算法的选择。
需要注意的是，MySQL 的 filesort使用的临时存储空间可能会超出你的预期，这是因为它对每个排序元素都分配了固定大小的存储空间。这些存储空间要足够大以便容下存储最大的元素，而且 VARCHAR这类字段使用的是对应的最大长度。而且，如果使用的是 UTF-8字符集，MuSQL 会对每个字符分配3个字节。结果是，我们会发现那些没怎么优化的查询会导致磁盘上的临时存储空间是数据表自身存储空间的好几倍。
而在对联合查询进行排序时，MySQL 可能会在查询执行过程中执行两次文件排序。如果 ORDER BY 子句只是引用联合查询的第一张表，MySQL 可以先对这个表进行文件排序，然后再处理联合查询。如果是这种情况，在 EXPLAIN 时会在 Extra 字段显示“Using filesort”。而对于其他的排序情况——例如排序不是针对第一张表，或者是 ORDER BY 使用的列对应了不止一个数据表，MySQL 必须使用临时表缓存查询结果，然而在联合查询完成后，再对临时表进行文件排序。在这种情况下，EXPLAIN 会在 Extra 字段显示“Using temorary; Using filesort”。如果包含 LIMIT 约束的话，会发生在文件排序后，因此临时表和文件排序的存储空间可能非常大。
MySQL 5.6在只需要对数据行的子集（例如 LIMIT）进行排序时，引入了一个重大改进。相对于对整个结果集进行排序再返回部分数据，MySQL 有时候会在排序的时候直接丢弃掉不需要的数据行来提高效率。不管怎么样，排序也需要小心使用，很可能会导致存储占用的飙升最终导致系统负荷过大。
