MySQL 会给每个线程分配一块内存用于排序，称为 sort_buffer。
假设找出在杭州居住的人，按名字排序前1000个人（假设city有索引，那么非常舒服，不用全表扫描）
select city,name,age from t where city='杭州' order by name limit 1000;全字段排序
具体流程是，先按照索引把所有满足city=’杭州’的数据的city、name、age字段都放到sort_buffer里（当然是一行一行扫描出来的），然后对sort_buffer中的数据进行排序，最后输出前1000个。
按 name 排序这个动作，可能在内存中完成，也可能需要使用外部排序，这取决于排序所需的内存和线程被分配用于排序的内存的大小sort_buffer_size。如果要排序的数据量小于 sort_buffer_size，排序就在内存中完成。但如果排序数据量太大，内存放不下，则不得不利用磁盘临时文件辅助排序。
number_of_tmp_files 代表用了12个外部临时文件辅助排序，外部排序一般使用归并排序算法。MySQL 将需要排序的数据分成 12 份，每一份单独排序后存在这些临时文件中。然后把这 12 个有序文件再合并成一个有序的大文件。
这里全部数据会被放到硬盘中，内存主要是用于计算排序过程和交互的
sort_mode 里面的 packed_additional_fields 的意思是，排序过程对字符串做了“紧凑”处理。即使 name 字段的定义是 varchar(16)，在排序过程中还是要按照实际长度来分配空间的，也就是说杭州被分配的是2个字符。
rowid排序
只对原表的数据读了一遍，剩下的操作都是在 sort_buffer 和临时文件中执行的。但这个算法有一个问题，就是如果查询要返回的字段很多的话，那么 sort_buffer 里面要放的字段数太多，这样内存里能够同时放下的行数很少，要分成很多个临时文件，排序的性能会很差。
所以可以只把主键和要排序的name放到sort_buffer中（执行过程与全字段排序一样），只不过排序好后，多了一次主键索引查找结果。
辅助排序的文件少了，sort_mode也变了，因为参与排序的字段变了。最重要的是虽然扫描行数仍然是4000，但实际上参与排序过程要读5000行，因为按照排序索引还要查1000行再给出结果
如何选择？
MySQL 的一个设计思想：如果内存够，就要多利用内存，尽量减少磁盘访问，IO 是数据库中最昂贵的操作！！！！！，也就是说优先全字段排序，那么什么时候才会用rowid呢？
当单行数据长度超过该值，MySQL 就会觉得如果还用全字段排序，会导致 sort buffer 容纳下的行数太少，从而转为使用 rowId 排序。通过参数 max_length_for_sort_data 可以控制用于排序的行数据最大长度，默认值为 1024 字节。也就是说被select放到sort_buffer里的字段一行超过1024字节，就会用rowid排序。
如何回避高昂的排序成本
可以看到实际上排序是很高成本的操作，但其实并不是所有order by都要执行上述排序操作，因为这一切都是数据无序存储的锅，假设有一个 city 和 name 的联合索引，那么符合city的自动就已经是按name排好序的了
可以看到没有Using filesort了，也就是不用外部排序了。只扫描前1000条数据就够
再进一步，假设索引就能确定一条数据，而不用主键了，就会更快
但这并不是鼓励无脑建立索引，因为建立维护索引是有代价的，需要权衡