产品中心
MySQL的Order By操作用于排序，并且会有多种不同的排序算法，他们的性能都是不一样的。
假设有一个表，建表的sql如下：
number_of_tmp_files表示排序过程中使用的临时辅助文件数。可以这么简单理解，MySQL将需要排序的数据分成12份，每一份单独排序后存在这些临时文件中。然后把这12个有序文件再合并成一个有序的大文件。
examined_rows表示参与排序的行数，一共5000行，即所有数据都参与了排序。
sort_mode 里面的packed_additional_fields的意思是，排序过程对字符串做了“紧凑”处理。即使a、b、c字段的定义是varchar(50)，在排序过程中还是要按照实际长度来分配空间的。
同时，最后一个查询语句select @b-@a 的返回结果是5000，表示整个执行过程只扫描了5000行。实际可能显示为5001，这是InnoDB的干扰，为了避免对结论造成干扰，可以把internal_tmp_disk_storage_engine参数设置成MyISAM。
可以看到examined_rows的值还是5000，表示用于排序的数据是5000行。但是select @b-@a这个语句的值变成8000了。因为这时候除了排序过程外，在排序完成后，还要根据id去原表取值。由于语句是limit 3000，因此会多读3000行。
sort_mode变成了<sort_key, rowid>，表示参与排序的只有a和id这两个字段，即rowid排序。
number_of_tmp_files变成3了，是因为这时候参与排序的行数虽然仍然是5000行，但是每一行的数据量都变小了，因此需要排序的总数据量就变小了，需要的临时文件也相应地变少了。
总结：
如果MySQL认为内存足够大，会优先选择全字段排序，把需要的字段都放到sort_buffer中，这样排序后就会直接从内存里面返回查询结果了，不用再回到原表去取数据，但这会导致它需要多次向临时文件写入内容，增加IO操作，当需要返回的列的总长度很长时尤其明显。而如果一行的数据大小超过max_length_for_sort_data这个限制值时，才会采用rowid排序算法，这样排序过程中一次可以排序更多行，但是需要再回到原表去取数据，即需要读两次表，并且第二次读取是随机的。
这也就体现了MySQL的一个设计思想：如果内存够，就要多利用内存，尽量减少磁盘访问。
从上面也能看出来，MySQL的排序操作的成本还是很高的，MySQL之所以需要生成临时表，并且在临时表上做排序操作，其原因是原来的数据都是无序的。
如果能够保证从b这个索引上取出来的行，天然就是递增排序的话，那就可以不用再排序了，这是就可以用到索引。
比如我们有如下查询：
如果number_of_tmp_files值为0，则可能是用到了优先队列排序算法，如果filesort_priority_queue_optimization部分的chosen=true，就表示使用了优先队列排序算法，这个过程不需要临时文件，因此对应的number_of_tmp_files是0。
因为limit所要取的数据量比较少，采用文件归并排序的话，就需要对全部数据进行排序，内存时间复杂度为O(nlogn)，但由于有文件IO实际需要更多时间。而如果使用优先队列排序，实际上就是堆排序，这样的排序是一种偏序排序，能够计算出所需的最大或者最小的几个值，但是其他的数据的顺序是不确定的，实际上如果使用堆排序对所有数据排序，那么时间复杂度也是O(nlogn)，但这里只需要在大量数据中取出少量有序数据，并且是内存中操作的，这样耗费的时间远小于文件归并排序。
如果limit取出的数据量小于sort_buffer_size，则采用优先队列排序。
到此这篇关于详解MySQL中Order By排序和filesort排序的原理及实现的文章就介绍到这了,更多相关MySQL Order By排序 filesort排序内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
