Mysql系列专栏之关于排序orderBy底层工作原理

你好，今天是Mysql专栏记录的第二篇讲一下Mysql的排序实现原理。每次开始一篇新的文章之前我都会和大家分享一下自己的感悟，最近也是一直在为找工作而准备相关知识点，其中Mysql因为在实际工作中用的比较多，也是重点想要了解的。每次看完一些文章记录都会反问自己这些知识点记住了吗？

也曾和我个人认为还不错的小伙伴交流他们当初是怎么学习的，两句话总结

1、这个技术解决了什么问题。

2、它的实现原理是什么，更通俗一点就是它是怎么做到的。

我也是希望带着这两个问题在看完每篇文章之后，反问自己的，也确实是一个不错的检验知识掌握程度的方法。

回到正题，Mysql的orderBy分为两种排序情况

第一种情况：全字段排序

通过Mysql的执行计划能够看见Extra附件信息中有使用到"Usingfile Sort"，表示就是需要排序，Mysql会为每个线程分配一块内存区域用于排序，这个区域就是sort_buffer

而排序这个动作可能是在内存里面也有可能利用磁盘的临时辅助文件来进行的

如果排序的数据量小于sort_buffer_size则在内存中进行，如果大于就在磁盘临时文件中进行

将数据拆分很多分在临时磁盘中处理，最后合并成一个总的文件，采用这种思路来进行的

缺点：就是行数据太大的话，会分成很多的临时文件来处理，这样造成性能比较差。

如果行数据比较大的话，可以采用以下第二种算法来排序

第二种情况：采用rowId来进行排序算法

参数设置：

SET max_length_for_sort_data = 16;

这种排序的思想就是根据你要排序的字段假如orderBy name，就将name和对应表的id主键进行排序

根据name找到id

根据id找到数据

然后排序

最后根据id再去表中查出其余剩下需要的字段来进行处理

缺点：最后还要再进行一次回表查询

 

对比：全字段排序  VS  rowId

全字段排序如何内存足够大，直接在内存中进行排序处理，但是也存在临时磁盘文件排序合并的问题

这样也从侧面反映了Mysql里面的设置理念：尽可能在内存中进行数据处理，避免不必要的磁盘I/O

rowId还需要回原表再查询一次，性能也不是最优。

其实上面的排序还有优化的思路

就是将查询条件的索引和排序字段组成联合索引，表示根据查询条件查询的内容就是排好序的，不需要再重新排序。

好了，今天的分享就到这里了，感谢~欢迎指正批评。