首页 / MYSQL / 【MySQL】排序原理与案例分析

【MySQL】排序原理与案例分析

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了【MySQL】排序原理与案例分析，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含12166字，纯文字阅读大概需要18分钟。

内容图文

假设表结构和SQL语句如下： 
CREATE TABLE t1(id int, col1 varchar(64), col2 varchar(64), col3 varchar(64), PRIMARY KEY(id),key(col1,col2));
SELECT col1,col2,col3 FROM t1 WHERE col1>100 ORDER BY col2;

a. 常规排序 

  • 从表t1中获取满足WHERE条件的记录
  • 对于每条记录，将记录的主键+排序键(id,col2)取出放入sort buffer
  • 如果sort buffer可以存放所有满足条件的(id,col2)对，则进行排序；否则sort buffer满后，进行排序并固化到临时文件中。(排序算法采用的是快速排序算法)
  • 若排序中产生了临时文件，需要利用归并排序算法，保证临时文件中记录是有序的
  • 循环执行上述过程，直到所有满足条件的记录全部参与排序
  • 扫描排好序的(id,col2)对，并利用id去捞取SELECT需要返回的列(col1,col2,col3)
  • 将获取的结果集返回给用户。

从上述流程来看，是否使用文件排序主要看sort buffer是否能容下需要排序的(id,col2)对，这个buffer的大小由sortbuffersize参数控制。此外一次排序需要两次IO，一次是捞(id,col2),第二次是捞(col1,col2,col3)，由于返回的结果集是按col2排序，因此id是乱序的，通过乱序的id去捞(col1,col2,col3)时会产生大量的随机IO。对于第二次MySQL本身一个优化，即在捞之前首先将id排序，并放入缓冲区，这个缓存区大小由参数readrndbuffer_size控制，然后有序去捞记录，将随机IO转为顺序IO。

b.优化排序

常规排序方式除了排序本身，还需要额外两次IO。优化的排序方式相对于常规排序，减少了第二次IO。主要区别在于，放入sort buffer不是(id,col2),而是(col1,col2,col3)。由于sort buffer中包含了查询需要的所有字段，因此排序完成后可以直接返回，无需二次捞数据。这种方式的代价在于，同样大小的sort buffer，能存放的(col1,col2,col3)数目要小于(id,col2)，如果sort buffer不够大，可能导致需要写临时文件，造成额外的IO。当然MySQL提供了参数maxlengthforsortdata，只有当排序元组小于maxlengthforsortdata时，才能利用优化排序方式，否则只能用常规排序方式。

c. 优先队列排序

为了得到最终的排序结果，无论怎样，我们都需要将所有满足条件的记录进行排序才能返回。那么相对于优化排序方式，是否还有优化空间呢？5.6版本针对Order by limit M，N语句，在空间层面做了优化，加入了一种新的排序方式--优先队列，这种方式采用堆排序实现。堆排序算法特征正好可以解limit M，N 这类排序的问题，虽然仍然需要所有元素参与排序，但是只需要M+N个元组的sort buffer空间即可，对于M，N很小的场景，基本不会因为sort buffer不够而导致需要临时文件进行归并排序的问题。对于升序，采用大顶堆，最终堆中的元素组成了最小的N个元素，对于降序，采用小顶堆，最终堆中的元素组成了最大的N的元素。

排序不一致问题

a. 案例1

Mysql从5.5迁移到5.6以后，发现分页出现了重复值。

测试表与数据：

create table t1(id int primary key, c1 int, c2 varchar(128));
insert into t1 values(1,1,‘a‘);
insert into t1 values(2,2,‘b‘);
insert into t1 values(3,2,‘c‘);
insert into t1 values(4,2,‘d‘);
insert into t1 values(5,3,‘e‘);
insert into t1 values(6,4,‘f‘);
insert into t1 values(7,5,‘g‘);

假设每页3条记录，第一页limit 0,3和第二页limit 3,3查询结果如下：

root@test 07:58:32>select * from t1 order by c1 asc limit 0,3;
+----+------+------+
| id | c1   | c2   |
+----+------+------+
|  1 |    1 | a    |
|  3 |    2 | c    |
|  4 |    2 | d    |
+----+------+------+
root@test 07:59:11>select * from t1 order by c1 asc limit 3,3;
+----+------+------+
| id | c1   | c2   |
+----+------+------+
|  4 |    2 | d    |
|  5 |    3 | e    |
|  6 |    4 | f    |
+----+------+------+

我们可以看到 id为4的这条记录居然同时出现在两次查询中，这明显是不符合预期的，而且在5.5版本中没有这个问题。产生这个现象的原因就是5.6针对limit M,N的语句采用了优先队列，而优先队列采用堆实现，比如上述的例子order by c1 asc limit 0，3 需要采用大小为3的大顶堆；limit 3，3需要采用大小为6的大顶堆。由于c1为2的记录有3条，而堆排序是非稳定的(对于相同的key值，无法保证排序后与排序前的位置一致)，所以导致分页重复的现象。为了避免这个问题，我们可以在排序中加上唯一值，比如主键id，这样由于id是唯一的，确保参与排序的key值不相同。将SQL写成如下：

select * from t1 order by c1,id asc limit 0,3;
select * from t1 order by c1,id asc limit 3,3;

b. 案例2

两个类似的查询语句，除了返回列不同，其它都相同，但排序的结果不一致。 测试表与数据

create table t2(id int primary key, status int, c1 varchar(255),c2 varchar(255),c3 varchar(255),key(c1));
insert into t2 values(7,1,‘a‘,repeat(‘a‘,255),repeat(‘a‘,255));
insert into t2 values(6,2,‘b‘,repeat(‘a‘,255),repeat(‘a‘,255));
insert into t2 values(5,2,‘c‘,repeat(‘a‘,255),repeat(‘a‘,255));
insert into t2 values(4,2,‘a‘,repeat(‘a‘,255),repeat(‘a‘,255));
insert into t2 values(3,3,‘b‘,repeat(‘a‘,255),repeat(‘a‘,255));
insert into t2 values(2,4,‘c‘,repeat(‘a‘,255),repeat(‘a‘,255));
insert into t2 values(1,5,‘a‘,repeat(‘a‘,255),repeat(‘a‘,255));

分别执行SQL语句：

select id,status,c1,c2 from t2 force index(c1) where c1>=‘b‘ order by status;
select id,status from t2 force index(c1) where c1>=‘b‘ order by status;

执行结果

root@test 08:01:24>select id,status,c1,c2 from t2 force index(c1) where c1>=‘b‘ order by status;
+----+--------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id | status | c1   | c2                                                                                                                                                                                                                                                              |
+----+--------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|  5 |      2 | c    | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
|  6 |      2 | b    | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
|  3 |      3 | b    | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
|  2 |      4 | c    | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
+----+--------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.00 sec)

root@test 08:01:31>select id,status from t2 force index(c1) where c1>=‘b‘ order by status;
+----+--------+
| id | status |
+----+--------+
|  6 |      2 |
|  5 |      2 |
|  3 |      3 |
|  2 |      4 |
+----+--------+
4 rows in set (0.00 sec)

看看两者的执行计划是否相同

root@test 08:08:10>explain select id,status,c1,c2 from t2 force index(c1) where c1>=‘b‘ order by status;     
+----+-------------+-------+-------+---------------+------+---------+------+------+---------------------------------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra                                 |
+----+-------------+-------+-------+---------------+------+---------+------+------+---------------------------------------+
|  1 | SIMPLE      | t2    | range | c1            | c1   | 768     | NULL |    4 | Using index condition; Using filesort |
+----+-------------+-------+-------+---------------+------+---------+------+------+---------------------------------------+

root@test 08:08:17>explain select id,status from t2 force index(c1) where c1>=‘b‘ order by status;                            
+----+-------------+-------+-------+---------------+------+---------+------+------+---------------------------------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra                                 |
+----+-------------+-------+-------+---------------+------+---------+------+------+---------------------------------------+
|  1 | SIMPLE      | t2    | range | c1            | c1   | 768     | NULL |    4 | Using index condition; Using filesort |
+----+-------------+-------+-------+---------------+------+---------+------+------+---------------------------------------+

为了说明问题，我在语句中加了force index的hint，确保能走上c1列索引。语句通过c1列索引捞取id，然后去表中捞取返回的列。根据c1列值的大小，记录在c1索引中的相对位置如下：

(c1,id)===(b,6),(b,3),(5,c),(c,2)，对应的status值分别为2 3 2 4。从表中捞取数据并按status排序，则相对位置变为(6,2,b),(5,2,c),(3,3,c),(2,4,c)，这就是第二条语句查询返回的结果，那么为什么第一条查询语句(6,2,b),(5,2,c)是调换顺序的呢？这里要看我之前提到的a.常规排序和b.优化排序中标红的部分，就可以明白原因了。由于第一条查询返回的列的字节数超过了maxlengthforsortdata，导致排序采用的是常规排序，而在这种情况下MYSQL将rowid排序，将随机IO转为顺序IO，所以返回的是5在前，6在后；而第二条查询采用的是优化排序，没有第二次捞取数据的过程，保持了排序后记录的相对位置。对于第一条语句，若想采用优化排序，我们将maxlengthforsortdata设置调大即可，比如2048。

root@test 08:11:24>select id,status,c1,c2 from t2 force index(c1) where c1>=‘b‘ order by status;
+----+--------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id | status | c1   | c2                                                                                                                                                                                                                                                              |
+----+--------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|  6 |      2 | b    | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
|  5 |      2 | c    | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
|  3 |      3 | b    | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
|  2 |      4 | c    | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa |
+----+--------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
参考
  1. MySQL排序原理与案例分析
  2. ORDER BY Optimization

【MySQL】排序原理与案例分析

标签：repeat   有序   5.6   性能   随机   sel   包含   extra   内存   

本文系统来源：http://www.cnblogs.com/zhiqian-ali/p/6017895.html

内容总结

以上是互联网集市为您收集整理的【MySQL】排序原理与案例分析全部内容，希望文章能够帮你解决【MySQL】排序原理与案例分析所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/472563.html

来源：【匿名】