在MySQL中的Order By 有2种排序实现方式

利用有序索引获取有序数据
文件排序

索引排序

取出满足过滤条件、作为排序条件的字段，以及可以直接定位到行数据的行指针信息，在 Sort Buffer 中进行实际的排序操作，然后利用排好序的数据根据行指针信息返回表中取得客户端请求的其他字段的数据，再返回给客户端。

这种方式，在使用explain分析查询的时候，显示Using index。而文件排序显示Using filesort。

按照索引对结果进行排序：order by 使用索引时有条件

首先创建个测试表，并插入些测试数据

CREATE TABLE `shop` ( 
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '记录ID', 
  `shop_id` int(11) NOT NULL COMMENT '商店ID', 
  `goods_id` int(11) NOT NULL COMMENT '物品ID', 
  `pay_type` tinyint(1) NOT NULL COMMENT '支付方式', 
  `price` decimal(10,2) NOT NULL COMMENT '物品价格', 
  `comment` varchar(200) NOT NULL COMMENT '备注', 
  PRIMARY KEY (`id`), 
  UNIQUE KEY `shop_id` (`shop_id`,`goods_id`), 
  KEY `price` (`price`), 
  KEY `pay_type` (`pay_type`) 
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 COMMENT='商店物品表' 
INSERT INTO `shop` (`id`, `shop_id`, `goods_id`, `pay_type`, `price`, `comment`) VALUES 
(1, 1, 1, 0, '1.00', ''), 
(2, 2, 1, 0, '24.00', ''), 
(3, 2, 3, 1, '5.99', ''), 
(4, 3, 1, 0, '1.99', ''), 
(5, 3, 2, 1, '81.00', ''), 
(6, 4, 2, 0, '15.00', ''), 
(7, 4, 3, 0, '22.00', '');

使用联合索引中的各个字段进行排序

可以通过Extra看到，使用了索引排序。

但是这里需要注意，必须满足覆盖索引的条件下，才会使用索引排序。下面列子

这里因为多检索了一列，造成没有覆盖索引，索引仍然不会使用索引排序。

另外，还可以强制指定索引，这样也可以应用上索引优化：

联合索引中的一部分指定了常量去检索，排序则使用了索引的另一部分

这种情况下，索引排序仍然是有效的。

排序方向变更

虽然改变了排序的方向，但是索引排序仍然有效。

索引的一部分为条件并且是常量，排序按索引的各字段倒排

对于何时排序优化有效，官方手册上是这样说的：

The index can also be used even if the ORDER BY does not match the index exactly, as long as all of the unused portions of the index and all the extra ORDER BY columns are constants in the WHERE clause.

翻译：

即使ORDER BY不精确匹配索引也能使用索引，只要WHERE子句中的所有未使用的索引部分和所有额外的ORDER BY列为常数就行。

在其他的情况下，mysql使用文件排序例如：

where语句与order by语句，使用了不同的索引
检查的行数过多，且没有使用覆盖索引
ORDER BY中的列不包含在相同的索引，也就是使用了不同的索引
对索引列同时使用了ASC和DESC
where语句或者ORDER BY语句中索引列使用了表达式，包括函数表达式
where 语句与ORDER BY语句组合满足最左前缀，但where语句中使用了条件查询
当使用left join，使用右边的表字段排序

文件排序

这个 filesort 并不是说通过磁盘文件进行排序，而只是告诉我们进行了一个排序操作。即在MySQL Query Optimizer 所给出的执行计划(通过 EXPLAIN 命令查看)中被称为文件排序（filesort）

文件排序是通过相应的排序算法,将取得的数据在内存中进行排序: MySQL需要将数据在内存中进行排序，所使用的内存区域也就是我们通过sort_buffer_size 系统变量所设置的排序区。这个排序区是每个Thread 独享的，所以说可能在同一时刻在MySQL 中可能存在多个 sort buffer 内存区域。

在MySQL中filesort 的实现算法实际上是有两种：

双路排序：是首先根据相应的条件取出相应的排序字段和可以直接定位行数据的行指针信息，然后在sort buffer 中进行排序。

单路排序：是一次性取出满足条件行的所有字段，然后在sort buffer中进行排序。

在MySQL4.1版本之前只有第一种排序算法双路排序，第二种算法是从MySQL4.1开始的改进算法，主要目的是为了减少第一次算法中需要两次访问表数据的 IO 操作，将两次变成了一次，但相应也会耗用更多的sortbuffer 空间。当然，MySQL4.1开始的以后所有版本同时也支持第一种算法。

MySQL主要通过比较我们所设定的系统参数 max_length_for_sort_data的大小和Query 语句所取出的字段类型大小总和来判定需要使用哪一种排序算法。如果 max_length_for_sort_data更大，则使用第二种优化后的算法，反之使用第一种算法。所以如果希望 ORDER BY 操作的效率尽可能的高，一定要主义max_length_for_sort_data 参数的设置。曾经就有同事的数据库出现大量的排序等待，造成系统负载很高，而且响应时间变得很长，最后查出正是因为MySQL 使用了传统的第一种排序算法而导致，在加大了max_length_for_sort_data 参数值之后，系统负载马上得到了大的缓解，响应也快了很多。

MySQL 需要使用Using temporary 临时表来filesort

如果order by的子句只引用了联接中的第一个表，MySQL会先对第一个表进行排序，然后进行联接。也就是expain中的Extra的Using Filesort.否则MySQL先把结果保存到临时表(Temporary Table),然后再对临时表的数据进行排序.此时expain中的Extra的显示Using temporary Using Filesort.

优化Filesort

当无法避免排序操作时，又该如何来优化呢？很显然，应该尽可能让 MySQL 选择使用第二种单路算法来进行排序。这样可以减少大量的随机IO操作，很大幅度地提高排序工作的效率。

1. 加大 max_length_for_sort_data 参数的设置

在 MySQL 中，决定使用老式排序算法还是改进版排序算法是通过参数 max_length_for_ sort_data 来决定的。当所有返回字段的最大长度小于这个参数值时，MySQL 就会选择改进后的排序算法，反之，则选择老式的算法。所以，如果有充足的内存让MySQL 存放须要返回的非排序字段，就可以加大这个参数的值来让 MySQL 选择使用改进版的排序算法。

2. 去掉不必要的返回字段

当内存不是很充裕时，不能简单地通过强行加大上面的参数来强迫 MySQL 去使用改进版的排序算法，否则可能会造成 MySQL 不得不将数据分成很多段，然后进行排序，这样可能会得不偿失。此时就须要去掉不必要的返回字段，让返回结果长度适应 max_length_for_sort_data 参数的限制。

3. 增大 sort_buffer_size 参数设置

增大 sort_buffer_size 并不是为了让 MySQL选择改进版的排序算法，而是为了让MySQL尽量减少在排序过程中对须要排序的数据进行分段，因为分段会造成 MySQL 不得不使用临时表来进行交换排序。

MySQL Order By 使用方法