MySQL- order by 是如何工作的？

1. 场景

在我们开发过程中，有时候会碰到根据指定的字段排序来显示结果的需求，我们一定会想到用order by语句来实现，例如

select city,name,age from t where city='杭州' order by name limit 1000  ;

我们只知道用它，但未必能真正了解它的执行流程和哪些参数会影响执行的行为。

准备工作

表的定义

CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `city` varchar(16) NOT NULL,
  `name` varchar(16) NOT NULL,
  `age` int(11) NOT NULL,
  `addr` varchar(128) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `city` (`city`)
) ENGINE=InnoDB;

2. 全字段排序

我们都知道索引可以避免全表扫描，我们需要在city字段上加上索引，我们先用explain命令来看看这个语句的执行情况。

Extra这个字段中的“Using filesort"表示的是需要排序，MySQL会给每个线程分配一块内存用于排序，称为sort_buffer。

执行流程

从图中我们可以看到，满足city=”杭州“条件的行，是从ID_X到ID_(X+N)的这些记录。这条执行语句大致分为以下几步：

1. 初始化sort_buffer，确定放入name,city,age三个字段
2. 从索引city找到第一个满足city="杭州"条件的主键id,也就是图中的ID_X
3. 到主键id索取出整行，取name、city、age三个字段的值，存入sort_buffer中。
4. 从索引city取下下一个记录的主键id;
5. 重复3、4直到city的值不满足查询条件为止，对应的主键id也就是图中的ID_Y
6. 对sort_buffer中的数据按照字段name做快速排序
7. 按照排序结果取前1000行返回客户端

图中”按name排序“这个动作，可能在内存中完成，也可能需要使用外部排序，这取决于排序所需的内存和参数sort_buffer_size大小。

sort_buffer_size也就是MySQL为排序开辟的内存的大小，如果要排序的数据量小于sort_buffer_size，排序就在内存中完成。如果排序数据量太大，内存放不下，则不得不使用磁盘临时文件辅助排序。

你可以用下面介绍的方法，来确定一个排序语句是否使用了临时文件。

/* 打开optimizer_trace，只对本线程有效 */
SET optimizer_trace='enabled=on'; 

/* @a保存Innodb_rows_read的初始值 */
select VARIABLE_VALUE into @a from  performance_schema.session_status where variable_name = 'Innodb_rows_read';

/* 执行语句 */
select city, name,age from t where city='杭州' order by name limit 1000; 

/* 查看 OPTIMIZER_TRACE 输出 */
SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`\G

/* @b保存Innodb_rows_read的当前值 */
select VARIABLE_VALUE into @b from performance_schema.session_status where variable_name = 'Innodb_rows_read';

/* 计算Innodb_rows_read差值 */
select @b-@a;

这个方法是通过查看OPTIMIZER_TRACE的结果来确认的，你可以从number_of_tmp_files中看到是否使用了临时文件

number_of_tmp_files表示的是排序过程中使用的临时文件数。你一定奇怪，为什么需要12个文件？内存放不下，就需要使用外部排序，外部排序一般使用归并算法。可以这么简单理解，MYSQL将需要排序的数据分成12份，每一份单独排序后存在这些临时文件中。然后把12个有序文件再合并成一个有序的大文件。

如果 sort_buffer_size 超过了需要排序的数据量的大小，number_of_tmp_files 就是 0，表示排序可以直接在内存中完成。否则就需要放在临时文件中排序。sort_buffer_size 越小，需要分成的份数越多，number_of_tmp_files 的值就越大

3. rowid排序

全字段排序好是好，但是如果要查询返回的字段很多的话怎么办？如果用全字段排序的方式进行，sort_buffer里面要放的字段数太多，从而导致内存里同时放下的行数很少，要分成很多临时文件，排序的性能会很差。所以如果单行很大，这个方法效率不够好。

我们可以修改一个参数，让MYSQL采用另外一种算法

SET max_length_for_sort_data = 16;

max_length_for_sort_data 是MYSQL中专门控制用于排序的行数据的长度的一个参数，意思是如果单行的长度超过这个值，MYSQL就认为单行太大，要换个算法。

city、name、age三个字段的定义总长度是36，我把max_length_for_sort_data设置为16，我们再来看看计算过程有什么改变。

新的算法放入sort_buffer的字段，只有要排序的列（即name字段）和主键id。

但这时，排序的结果就因为少了city和age字段，不能直接返回了，整个流程变成了这样:

1. 初始化 sort_buffer，确定放入两个字段，即 name 和 id；
2. 从索引 city 找到第一个满足 city='杭州’条件的主键 id，也就是图中的 ID_X；
3. 到主键 id 索引取出整行，取 name、id 这两个字段，存入 sort_buffer 中；
4. 从索引 city 取下一个记录的主键 id；
5. 重复步骤 3、4 直到不满足 city='杭州’条件为止，也就是图中的 ID_Y；
6. 对 sort_buffer 中的数据按照字段 name 进行排序；
7. 遍历排序结果，取前 1000 行，并按照 id 的值回到原表中取出 city、name 和 age 三个字段返回给客户端。

对比全字段排序，rowid排序多访问了一次表t的主键索引，就是步骤7。

需要说明的是，最后的“结果集”是一个逻辑概念，实际上 MySQL 服务端从排序后的 sort_buffer 中依次取出 id，然后到原表查到 city、name 和 age 这三个字段的结果，不需要在服务端再耗费内存存储结果，是直接返回给客户端的。

4. 全字段排序 vs rowid 排序

如果MYSQL担心排序内存太小，则会影响排序效率，才会使用rowid排序，但是这样排序过程中一次可以排序更多行，需要再会到原表取数据。如果MYSQL认为内存足够大，则优先选择全字段排序，把需要的字段放到sort_buffer中，这样排序后就会直接从内存里面返回查询结果了，不需要再回到原表取数据。

这也体现了MYSQL的一个设计思想:如果内存足够大，就要多利用内存，尽量减少磁盘访问。对于InnoDB表来说，rowid排序会要求回表多造成磁盘读，因此不会被优先选择。

5. 覆盖索引的好处

order by语句并不是所有语句都需要排序操作。从上面分析的执行过程，我们可以看到，MYSQL之所以需要生成临时表，并且在临时表上做排序操作，其原因是原来的数据都是无序的。

如果能够保证从city这个索引上取出来的行，天然就是按照name递增排序的话，是不是可以不用在排序了呢？

确实是这样，我们可以在这个市民表上创建一个city和name的联合索引，对应的SQL语句是:

alter table t add index city_user(city, name);

作为与city索引的对比，我们来看看这个索引的示意图。

这时，对于city字段的值相同的行来说，还是按照name字段的值递增顺序的，此时的查询语句也就不需要排序了，流程如下:

1. 从索引 (city,name,age) 找到第一个满足 city='杭州’条件的记录，取出其中的 city、name 和 age 这三个字段的值，作为结果集的一部分直接返回；
2. 从索引 (city,name,age) 取下一个记录，同样取出这三个字段的值，作为结果集的一部分直接返回；
3. 重复执行步骤 2，直到查到第 1000 条记录，或者是不满足 city='杭州’条件时循环结束。

我们来看看explain结果。

可以看到，Extra字段里面多了"Using index",表示的就是使用了覆盖索引，性能会快很多。当然，这里并不是说要为了每个查询能用上覆盖索引，就要把语句中涉及的字段都建上联合索引，毕竟索引还是有维护代价的，这需要进行权衡。