MySQL中order by的执行过程


Posted in MySQL onJune 05, 2022

前言:

在开发过程中,一定会经常碰到需要根据指定的字段排序来显示结果的需求。还是以前文的订单表为例,假设查询“张三”的所有订单,并且按照订单价格排序返回前 1000 个订单号以及价格。

一 、测试数据

测试的这个订单表my_order的结构是这样的:

CREATE TABLE `my_order` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `oid` varchar(20) NOT NULL,
  `uid` int(11) NOT NULL,
  `price` decimal(6,2) NOT NULL DEFAULT '0.00',
  PRIMARY KEY (`id`) USING BTREE,
  KEY `uid` (`uid`) USING BTREE,
  KEY `oid` (`oid`)
) ENGINE=InnoDB AUTO_INCREMENT=1000000 DEFAULT CHARSET=utf8;

MySQL中order by的执行过程

用户表my_user数据:

MySQL中order by的执行过程

上面的订单表my_order的uid 与 用户表my_user的id 关联。

SQL 语句可以这么写:

SELECT
	oid,
	price 
FROM
	my_order 
WHERE
	uid = 1 
ORDER BY
	price 
	LIMIT 1000;

上面的SQL语句看上去逻辑很清晰,但是它的执行流程了解么?这篇文章就来学习一下这个语句是怎么执行的,以及有哪些参数会影响执行。

二、 全字段排序

为避免全表扫描,我们需要在 uid 字段加上索引。在 uid 字段加上索引之后,我们用 EXPLAIN 命令来看看这个语句的执行情况。

MySQL中order by的执行过程

Extra 这个字段中的“Using filesort”表示的就是需要排序,MySQL 会给每个线程分配一块内存用于排序,称为 sort_buffer。为了说明这个 SQL 查询语句的执行过程,我们先看一下 uid 这个索引的示意图。

如下图所示:

MySQL中order by的执行过程

通常情况下,这个语句执行流程如下 :

  • 初始化 sort_buffer,确定放入 oid、price、uid 这三个字段;
  • 从索引 uid 找到第一个满足 uid = 1 条件的主键 id,也就是图中的 ID-4;
  • 到主键 id 索引取出整行,取 oid、price、uid 三个字段的值,存入 sort_buffer 中;
  • 从索引 uid 取下一个记录的主键 id;
  • 重复步骤 3、4 直到 uid 的值不满足查询条件为止;
  • 对 sort_buffer 中的数据按照字段 oid 做快速排序;
  • 按照排序结果取前 1000 行返回给客户端。

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

sort_buffer_size,就是 MySQL 为排序开辟的内存(sort_buffer)的大小。如果要排序的数据量小于 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 oid,price FROM my_order WHERE uid=1 ORDER BY price 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 中看到是否使用了临时文件。

MySQL中order by的执行过程

number_of_tmp_files 表示排序过程中使用的临时文件数。你一定奇怪,我当前测试的需要 0 个文件,表示排序可以直接在内存中完成。如果是 n,则表示内存放不下时,就需要使用外部排序,外部排序一般使用归并排序算法。可简单理解,MySQL 将需要排序的数据分成 n 份,每一份单独排序后存在这些临时文件中。然后把这 n 个有序文件再合并成一个有序的大文件。

注:当如果sort_buffer_size超过了需要排序的数据量的大小,number_of_tmp_files 就是 0,表示排序可以直接在内存中完成。

接下来,我再和你解释一下上图中其他两个值的意思。

我们的示例表中有 99972 条满足 uid = 1 的记录,examined_rows=99972,表示参与排序的行数是 99972 行。

sort_mode 里面是 additional_fields。

  • 1、< sort_key, rowid > 对应的是MySQL 4.1之前的"原始排序模式"。表明排序缓冲区元组包含排序键值和原始表⾏的⾏id,排序后需要使⽤⾏id进⾏回表,这种算法也称为original filesort algorithm(回表排序算法);
  • 2、< sort_key, additional_fields > 对应的是MySQL 4.1以后引入的"修改后排序模式"。排序缓冲区元组包含排序键值和查询所需要的列,排序后直接从缓冲区元组取数据,⽆需回表,这种算法也称为modified filesort algorithm(不回表排序);
  • 3、< sort_key, packed_additional_fields > 是MySQL 5.7.3以后引入的进一步优化的"打包数据排序模式"。这类似上⼀种形式,但是附加的列(如varchar类型)紧密地打包在⼀起,⽽不是使⽤固定长度的编码。

同时,最后一个查询语句 select @b-@a 的返回结果是 99973。

那为啥不是上面那个 99972 呢?

这里需要注意的是,为了避免干扰,你可以把 internal_tmp_disk_storage_engine 设置成 MyISAM。否则,select @b-@a 的结果会显示为 99973。这是因为查询 OPTIMIZER_TRACE 这个表时,需要用到临时表,而 internal_tmp_disk_storage_engine 的默认值是 InnoDB。如果使用的是 InnoDB 引擎的话,把数据从临时表取出来的时候,会让 Innodb_rows_read 的值加 1。

MySQL中order by的执行过程

三、rowid 排序

上面那个算法,只对原表的数据读了一遍,剩下的操作都是在 sort_buffer 和临时文件中执行的。但这个算法有一个问题,就是如果查询要返回的字段很多的话,那么 sort_buffer 里面要放的字段数太多,这样内存里能够同时放下的行数很少,要分成很多个临时文件,排序的性能会很差。所以如果单行很大,这个方法效率不够好。

如果 MySQL 认为排序的单行长度太大会怎么做呢?

下面来修改一个参数,让 MySQL 采用另外一种算法。

SET max_length_for_sort_data = 16;

max_length_for_sort_data,是 MySQL 中专门控制用于排序的行数据的长度的一个参数。它的意思是,如果单行的长度超过这个值,MySQL 就认为单行太大,要换一个算法。oid、price这2个字段的定义总长度是 28,我把 max_length_for_sort_data 设置为 16,我们再来看看计算过程有什么改变。新的算法放入 sort_buffer 的字段,只有要排序的列(即 price 字段)和主键 id。但这时,排序的结果就因为少了 price 字段的值,不能直接返回了,

整个执行流程就变成如下所示的样子:

  • 初始化 sort_buffer,确定放入两个字段,即 price 和 id;
  • 从索引 uid 找到第一个满足 uid= 1 条件的主键 id;
  • 到主键 id 索引取出整行,取 price、id 这两个字段,存入 sort_buffer 中;
  • 从索引 uid 取下一个记录的主键 id;
  • 重复步骤 3、4 直到不满足 uid= 1 条件为止;
  • 对 sort_buffer 中的数据按照字段 price 进行排序;
  • 遍历排序结果,取前 1000 行,并按照 id 的值回到原表中取出 oid、price 2个字段返回给客户端。

对比全字段排序流程图,rowid 排序多访问了一次表 test 的主键索引,就是步骤 7。

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

那么根据这个时候执行 select @b-@a,结果会是多少呢?

首先,图中的 examined_rows 的值还是 99972,表示用于排序的数据是 99972 行。但是 select @b-@a 这个语句的值变成 100973 了。(比上面的 select @b-@a 99973 多了1000行,因为这时候除了排序过程外,在排序完成后,还要根据 id 去原表取值。由于语句是 limit 1000,因此会多读 1000 行)。

MySQL中order by的执行过程

MySQL中order by的执行过程

从 OPTIMIZER_TRACE 的结果中,你还能看到另外有个信息也变了。

  • sort_mode 变成了 <sort_key, rowid>,表示参与排序的只有 price 和 id 这两个字段。

四、全字段排序 与 rowid 排序 比较

如果 MySQL 实在是担心排序内存太小,会影响排序效率,才会采用 rowid 排序算法,这样排序过程中一次可以排序更多行,但是需要再回到原表去取数据。

如果 MySQL 认为内存足够大,会优先选择全字段排序,把需要的字段都放到 sort_buffer 中,这样排序后就会直接从内存里面返回查询结果了,不用再回到原表去取数据。这也就体现了 MySQL 的一个设计思想:如果内存够,就要多利用内存,尽量减少磁盘访问。对于 InnoDB 表来说,rowid 排序会要求回表多造成磁盘读,因此不会被优先选择。

MySQL 做排序是一个成本比较高的操作。是不是所有的 order by 都需要排序操作呢?如果不排序就能得到正确的结果,那对系统的消耗会小很多,语句的执行时间也会变得更短。其实,并不是所有的 order by 语句,都需要排序操作的。从上面分析的执行过程,我们可以看到,MySQL 之所以需要生成临时表,并且在临时表上做排序操作,其原因是原来的数据都是无序的。如果能够保证从 uid 这个索引上取出来的行,天然就是按照 price 递增排序的话,是不是就可以不用再排序了呢?所以,我们可以在这个市民表上创建一个 uid 和 price 的联合索引,对应的 SQL 语句是:

ALTER TABLE my_order ADD INDEX un_key (uid,price);

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

MySQL中order by的执行过程

在这个索引里面,我们依然可以用树搜索的方式定位到第一个满足 uid=1 的记录,并且额外确保了,接下来按顺序取“下一条记录”的遍历过程中,只要 uid 的值是 1,price 的值就一定是有序的。

这样整个查询过程的流程就变成了:

  • 从索引 (uid,price) 找到第一个满足 city= 1 条件的主键 id;
  • 到主键 id 索引取出整行,取 oid、price 2个字段的值,作为结果集的一部分直接返回;
  • 从索引 (uid,price) 取下一个记录主键 id;
  • 重复步骤 2、3,直到查到第 1000 条记录,或者是不满足 uid=1 条件时循环结束。

这个查询过程不需要临时表,也不需要排序。接下来,我们用 EXPLAIN 的结果来印证一下。

MySQL中order by的执行过程

从图中可以看到,Extra 字段中没有 Using filesort 了,也就是不需要排序了。而且由于 (uid,price) 这个联合索引本身有序,所以这个查询也不用把 99972 行全都读一遍,只要找到满足条件的前 1000 条记录就可以退出了。也就是说,在我们这个例子里,只需要扫描 1000 次。同样看下 select @b-@a;

MySQL中order by的执行过程

再稍微复习一下。覆盖索引是指,索引上的信息足够满足查询请求,不需要再回到主键索引上去取数据。Extra 字段里面多了“Using index”,表示的就是使用了覆盖索引,性能上会快很多。

当然,这里并不是说要为了每个查询能用上覆盖索引,就要把语句中涉及的字段都建上联合索引,毕竟索引还是有维护代价的。这是一个需要权衡的决定。

到此这篇关于MySQL中order by的执行过程的文章就介绍到这了,更多相关MySQL order by 内容请搜索三水点靠木以前的文章或继续浏览下面的相关文章希望大家以后多多支持三水点靠木!

MySQL 相关文章推荐
数据库连接池
Apr 06 MySQL
MySQL InnoDB ReplicaSet(副本集)简单介绍
Apr 24 MySQL
MySQL Router的安装部署
Apr 24 MySQL
MySQL数据库压缩版本安装与配置详细教程
May 21 MySQL
MySQL CHAR和VARCHAR该如何选择
May 31 MySQL
Mysql实现主从配置和多主多从配置
Jun 02 MySQL
MySql 缓存查询原理与缓存监控和索引监控介绍
Jul 02 MySQL
浅谈MySQL之select优化方案
Aug 07 MySQL
Mysql如何实现不存在则插入,存在则更新
Mar 25 MySQL
mysql中数据库覆盖导入的几种方式总结
Mar 25 MySQL
Windows下载并安装MySQL8.0.x 版本的完整教程
Apr 10 MySQL
MySQL新手入门进阶语句汇总
Sep 23 MySQL
MySQL 语句执行顺序举例解析
Jun 05 #MySQL
MySql数据库触发器使用教程
Jun 01 #MySQL
MySQL选择合适的备份策略和备份工具
MySQL普通表如何转换成分区表
May 30 #MySQL
Mysql将字符串按照指定字符分割的正确方法
May 30 #MySQL
MySQL数据库安装方法与图形化管理工具介绍
MySQL数据库简介与基本操作
May 30 #MySQL
You might like
php实现判断访问来路是否为搜索引擎机器人的方法
2015/04/15 PHP
Laravel框架模型的创建及模型对数据操作示例
2019/05/07 PHP
Extjs学习笔记之七 布局
2010/01/08 Javascript
jquery特效 幻灯片效果示例代码
2013/07/16 Javascript
jquery实现简单易懂的图片展示小例子
2013/11/21 Javascript
各浏览器对document.getElementById等方法的实现差异解析
2013/12/05 Javascript
JS根据变量保存方法名并执行方法示例
2014/04/04 Javascript
jQuery中insertAfter()方法用法实例
2015/01/08 Javascript
简介JavaScript中substring()方法的使用
2015/06/06 Javascript
js代码实现无缝滚动(文字和图片)
2015/08/20 Javascript
js实现浮动在网页右侧的简洁QQ在线客服代码
2015/09/04 Javascript
JS实现选中当前菜单后高亮显示的导航条效果
2015/10/15 Javascript
jquery.validate提示错误信息位置方法
2016/01/22 Javascript
jquery实现全选、不选、反选的两种方法
2016/09/06 Javascript
B/S(Web)实时通讯解决方案分享
2017/04/06 Javascript
详谈jQuery.load()和Jsp的include的区别
2017/04/12 jQuery
JavaScript学习笔记之数组基本操作示例
2019/01/09 Javascript
Layui数据表格跳转到指定页的实现方法
2019/09/05 Javascript
微信小程序登录时如何获取input框中的内容
2019/12/04 Javascript
vue中h5端打开app(判断是安卓还是苹果)
2021/02/26 Vue.js
python通过post提交数据的方法
2015/05/06 Python
windows下ipython的安装与使用详解
2016/10/20 Python
Diango + uwsgi + nginx项目部署的全过程(可外网访问)
2018/04/22 Python
Python函数返回不定数量的值方法
2019/01/22 Python
python 绘制拟合曲线并加指定点标识的实现
2019/07/10 Python
Pycharm远程调试原理及具体配置详解
2019/08/08 Python
python logging日志模块原理及操作解析
2019/10/12 Python
Python字典常见操作实例小结【定义、添加、删除、遍历】
2019/10/25 Python
python 爬虫百度地图的信息界面的实现方法
2019/10/27 Python
Python递归调用实现数字累加的代码
2020/02/25 Python
python爬虫使用requests发送post请求示例详解
2020/08/05 Python
CSS3实现超酷的黑猫警长首页
2016/04/26 HTML / CSS
员工趣味活动方案
2014/08/27 职场文书
七夕情人节问候语
2015/11/11 职场文书
《悬崖边的树》读后感2篇
2019/12/02 职场文书
React中的Context应用场景分析
2021/06/11 Javascript