MySQL:关于排序order by limit值不稳定的说明（1）

最新推荐文章于 2024-06-22 21:31:42 发布
最新推荐文章于 2024-06-22 21:31:42 发布
阅读量6.5k 收藏 3
点赞数 1

 导 读

作者：高鹏（重庆八怪）

原文地址：

https://www.jianshu.com/p/8c2154872f83

本系列文章将持续更新，欢迎关注~

作者按：如果有误请谅解和指正，本文仅仅作为抛砖引玉，欢迎交流拍砖，谢谢！


源码版本：5.7.14
本文约定：PQ 就是  Priority Queue 及优先队列其实现算法是堆排序。

一、问题抛出

数据如下：

CREATE TABLE `testse` (
  `id` int(11) NOT NULL,
  `nu` int(11) DEFAULT NULL,
  `name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `nu` (`nu`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


INSERT INTO `testse` VALUES (-1,14,'gaopeng'),(0,14,'gaopeng'),(1,1,'gaopeng'),(2,99,'gaopeng'),(3,55,'gaopeng'),(4,20,'gaopeng'),(5,24,'gaopeng'),(6,14,'gaopeng'),(7,1
4,'gaopeng'),(8,13,'gaopeng'),(9,9,'gaopeng'),(10,19,'gaopeng'),(11,20,'gaopeng'),(12,14,'gaopeng'),(13,15,'gaopeng'),(14,16,'gaopeng'),(15,20,'gaopeng'),(100,14,'gaope
ng'),(111,14,'gaopeng');

问题如下：

mysql>  select *  from testse order by  nu limit 3,1;
+-----+------+---------+
| id  | nu   | name    |
+-----+------+---------+
| 111 |   14 | gaopeng |
+-----+------+---------+
1 row in set (2.76 sec)

mysql>  select *  from testse force index(nu) order by  nu limit 3,1;
+----+------+---------+
| id | nu   | name    |
+----+------+---------+
| -1 |   14 | gaopeng |
+----+------+---------+
1 row in set (0.00 sec)

问为什么这两个语句得到的数据不一样？

二、问题原因

这里首先给出原因：在MySQL排序的时候可以使用索引来避免排序及不需要使用filesort，其次当使用filesort的时候可能在内存中出现两种情况及堆排序列和快速排序两种方式。所以MySQL内存排序可以使用的途径包含：

  • 直接利用索引避免排序

  • 快速排序

  • 堆排序

具体使用哪一种排序方式是优化器决定的，总的说来如下：

  • 直接利用索引避免排序：用于有索引且回表效率高的情况下

  • 快速排序算法：如果没有索引大量排序的情况下

  • 堆排序算法：如果没有索引排序量不大的情况下

而快速排序和堆排序是不稳定的排序算法，也就是对于重复值是不能保证顺序的。而直接利用索引的话其返回数据是稳定的，因为索引的B+树叶子结点的顺序是唯一且一定的。如上的key nu，其叶子结点包含了nu+id，它是唯一的顺序也是递增的。因此在这种不稳定的算法情况下上面的查询出现了不一样的结果，归根结底就是使用索引避免排序和堆排序对于重复值的处理上是不同的。
也许你会问为什么存在两种排序方式，实际上在大量排序的情况下快速排序是有优势的，而堆排序使用优先队列只完成少量的排序是有优势的，因为它根本不需要排序完成只排序你需要的数据量就可以了。

MySQL认为快速排序的速度是堆排序的3倍如下：

/*
    How much Priority Queue sort is slower than qsort.
    Measurements (see unit test) indicate that PQ is roughly 3 times slower.
  */
  const double PQ_slowness= 3.0;

那么在使用排序算法的时候会根据待排序数据量的大小进行切换具体根据函数check_if_pq_applicable进行判定的。在filesort函数里面有如下代码：

if (check_if_pq_applicable(trace, &param, &table_sort,
                             table, num_rows, memory_available,
                             subselect != NULL))
  {
    DBUG_PRINT("info", ("filesort PQ is applicable")); //使用堆排序
    /*
      For PQ queries (with limit) we know exactly how many pointers/records
      we have in the buffer, so to simplify things, we initialize
      all pointers here. (We cannot pack fields anyways, so there is no
      point in doing lazy initialization).
     */
    table_sort.init_record_pointers();
    .....
   filesort->using_pq= true;
    param.using_pq= true;
  }
  else//使用快速排序
  {
    DBUG_PRINT("info", ("filesort PQ is not applicable"));
    filesort->using_pq= false;
    param.using_pq= false;

 .....
  }

三、如何确定是使用的哪种方法返回排序的结果

对于直接利用索引避免排序，这个直接看执行计划就好了，不会出现filesort字样。但是对于到底使用额快速排序还是堆排序则不好判断因为执行计划是一样的，我想到的只能是在调试的时候做断点，不知道还有其他办法没有。因此我在上面代码的if分支里面做了2个断点，其中一个断点在堆排序算法里面，一个断点在快速排序算法里面如下：

3       breakpoint     keep y   0x0000000000f50e62 in filesort(THD*, Filesort*, bool, ha_rows*, ha_rows*, ha_rows*)
                                               at /root/mysql5.7.14/percona-server-5.7.14-7/sql/filesort.cc:359
        breakpoint already hit 3 times
4       breakpoint     keep y   0x0000000000f50d41 in filesort(THD*, Filesort*, bool, ha_rows*, ha_rows*, ha_rows*)
                                               at /root/mysql5.7.14/percona-server-5.7.14-7/sql/filesort.cc:333
        breakpoint already hit 1 time

其中断点3代表快速排序命中，断点4代表堆排序命中。

四、额外的测试

如上所述我们可以将结果的返回定义为三种方式，我们将在这里测试这三种方式的得到数据不同。

  • 使用索引避免排序的结果

语句：
select *  from testse force index(nu) order by  nu;

mysql> desc select *  from testse force index(nu) order by  nu;
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table  | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra |
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------+
|  1 | SIMPLE      | testse | NULL       | index | NULL          | nu   | 5       | NULL |   19 |   100.00 | NULL  |
+----+-------------+--------+------------+-------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> select *  from testse force index(nu) order by  nu;
+-----+------+---------+
| id  | nu   | name    |
+-----+------+---------+
|   1 |    1 | gaopeng |
|   9 |    9 | gaopeng |
|   8 |   13 | gaopeng |
|  -1 |   14 | gaopeng |
|   0 |   14 | gaopeng |
|   6 |   14 | gaopeng |
|   7 |   14 | gaopeng |
|  12 |   14 | gaopeng |
| 100 |   14 | gaopeng |
| 111 |   14 | gaopeng |
|  13 |   15 | gaopeng |
|  14 |   16 | gaopeng |
|  10 |   19 | gaopeng |
|   4 |   20 | gaopeng |
|  11 |   20 | gaopeng |
|  15 |   20 | gaopeng |
|   5 |   24 | gaopeng |
|   3 |   55 | gaopeng |
|   2 |   99 | gaopeng |
+-----+------+---------+
19 rows in set (0.01 sec)


  • 使用快速排序的结果

语句：
select *  from testse order by  nu;

因为我前面设置了断点，其断点命中如下：

Breakpoint 3, filesort (thd=0x7fff300128c0, filesort=0x7fff30963e90, sort_positions=false, examined_rows=0x7ffff01158a0, found_rows=0x7ffff0115898, 
    returned_rows=0x7ffff0115890) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/filesort.cc:359
359         DBUG_PRINT("info", ("filesort PQ is not applicable"));

可以看到PQ 没有开启，也就是堆排序没有使用使用的优先队列堆排序方式。那么它的结果是：

mysql> desc select *  from testse order by  nu;
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | testse | NULL       | ALL  | NULL          | NULL | NULL    | NULL |   19 |   100.00 | Using filesort |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)

mysql> select *  from testse order by  nu;
+-----+------+---------+
| id  | nu   | name    |
+-----+------+---------+
|   1 |    1 | gaopeng |
|   9 |    9 | gaopeng |
|   8 |   13 | gaopeng |
| 111 |   14 | gaopeng |
| 100 |   14 | gaopeng |
|  12 |   14 | gaopeng |
|   7 |   14 | gaopeng |
|   6 |   14 | gaopeng |
|   0 |   14 | gaopeng |
|  -1 |   14 | gaopeng |
|  13 |   15 | gaopeng |
|  14 |   16 | gaopeng |
|  10 |   19 | gaopeng |
|   4 |   20 | gaopeng |
|  11 |   20 | gaopeng |
|  15 |   20 | gaopeng |
|   5 |   24 | gaopeng |
|   3 |   55 | gaopeng |
|   2 |   99 | gaopeng |
+-----+------+---------+
19 rows in set (1.74 sec)

  • 使用堆排序

语句：
select *  from testse order by  nu limit 8;

其断点命中

Breakpoint 4, filesort (thd=0x7fff300128c0, filesort=0x7fff3095ecc8, sort_positions=false, examined_rows=0x7ffff01158a0, found_rows=0x7ffff0115898, 
    returned_rows=0x7ffff0115890) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/filesort.cc:333
333         DBUG_PRINT("info", ("filesort PQ is applicable"));

可以看到PQ 开启了，也就是堆排序。

mysql> desc  select *  from testse order by  nu limit 8;
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table  | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | testse | NULL       | ALL  | NULL          | NULL | NULL    | NULL |   19 |   100.00 | Using filesort |
+----+-------------+--------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)

mysql> select *  from testse order by  nu limit 8;
+-----+------+---------+
| id  | nu   | name    |
+-----+------+---------+
|   1 |    1 | gaopeng |
|   9 |    9 | gaopeng |
|   8 |   13 | gaopeng |
|  -1 |   14 | gaopeng |
|   0 |   14 | gaopeng |
|  12 |   14 | gaopeng |
| 111 |   14 | gaopeng |
|   6 |   14 | gaopeng |
+-----+------+---------+
8 rows in set (2.20 sec)

可以看到从前面8行来看，每种方法返回的数据是不一样的：

使用索引避免排序：
+-----+------+---------+
| id  | nu   | name    |
+-----+------+---------+
|   1 |    1 | gaopeng |
|   9 |    9 | gaopeng |
|   8 |   13 | gaopeng |
|  -1 |   14 | gaopeng |
|   0 |   14 | gaopeng |
|   6 |   14 | gaopeng |
|   7 |   14 | gaopeng |
|  12 |   14 | gaopeng |


使用快速排序：

+-----+------+---------+
| id  | nu   | name    |
+-----+------+---------+
|   1 |    1 | gaopeng |
|   9 |    9 | gaopeng |
|   8 |   13 | gaopeng |
| 111 |   14 | gaopeng |
| 100 |   14 | gaopeng |
|  12 |   14 | gaopeng |
|   7 |   14 | gaopeng |
|   6 |   14 | gaopeng |

使用堆排序：
+-----+------+---------+
| id  | nu   | name    |
+-----+------+---------+
|   1 |    1 | gaopeng |
|   9 |    9 | gaopeng |
|   8 |   13 | gaopeng |
|  -1 |   14 | gaopeng |
|   0 |   14 | gaopeng |
|  12 |   14 | gaopeng |
| 111 |   14 | gaopeng |
|   6 |   14 | gaopeng |
+-----+------+---------+


五、总结

可以看到在不同的获取数据的方式得到的数据是不一样的，但是这只是重复数据排序的部分，这是排序算法的不稳定性决定的。快速排序适合大数据量排序，堆排序在少量排序上有优势，因此当order by limit n，n到了一个数量级的时候会切换排序算法，这个在执行计划是看不到的，具体使用那种算法是优化器通过函数check_if_pq_applicable进行判定的。
其次这只是一种造成排序数据不一致的情况还有一种情况是由于参数 max_length_for_sort_data的参数影响的一次排序和二次排序，这个有机会在研究一下代码。一般默认1024个字节还是很少会超过的。

六、堆排序算法简单说明

最后我还是想简单描述一下堆排序算法，也当复习一下。具体可以参考算法导论等书籍，我们以大顶堆为例，实际上任何一个待排序的数组都可以看成一棵完全二叉树，用算法导论的截图如下：

640?wx_fmt=png

这棵树是满足大顶堆定义的，在大顶堆中有如下特性：

  • 必须满足完全二叉树
    关于完全二叉树参考
    http://blog.itpub.net/7728585/viewspace-2125889/

  • 很方便的根据父节点的位置计算出两个叶子结点的位置
    如果父节点的位置为i/2，左子节点为 i，右子节点为i+1这是完全二叉树的特性决定

  • 所有子节点都可以看做一个子堆那么所有结点都有
    父节点>左子节点 && 父节点>右节点

  • 很明显的可以找到最大的元素，就是整个堆的根结点

在这个算法中，最重要也是最主要的就是堆的维护，堆的构建。

  • 维护：
    维护：采用的是自上而下的维护，可以用递归完成。
    这里电子版有点不清晰，黑色结点就是值4

640?wx_fmt=other

  • 构建
    构建：是采用自下而上的构建，构建就是不断循环的对各个父结点做维护，以达到对任何一个无序数组满足大顶堆的条件。因为下层的子树满足了大顶堆条件那么上层就一定满足大顶堆的条件。

640?wx_fmt=other

640?wx_fmt=other

  • 排序

实际上排序就是将数组中的第一个数字也就是最大的数字和最后一个数字交换，然后再次做一次维护做好大顶堆结构即可，如果反复不断做这个操作那么整个数组都会排序完成。


640?wx_fmt=other


640?wx_fmt=png

对于MySQL的源码中堆排序的代码存在于priority_queue.h文件中，其中可以看到一些方法如：

  • 维护 heapify函数

  • 构建 build_heap函数

  • 排序 sort函数
    当然源码的实现复杂得多，有兴趣的朋友可以深入。栈帧备查：

#0  Priority_queue<uchar*, std::vector<uchar*, Malloc_allocator<uchar*> >, <unnamed>::Mem_compare>::heapify(size_t, size_t) (this=0x7ffff0115650, i=0, last=8)
    at /root/mysql5.7.14/percona-server-5.7.14-7/include/priority_queue.h:124
#1  0x0000000000f5807a in Priority_queue<uchar*, std::vector<uchar*, Malloc_allocator<uchar*> >, <unnamed>::Mem_compare>::heapify(size_t) (this=0x7ffff0115650, i=0)
    at /root/mysql5.7.14/percona-server-5.7.14-7/include/priority_queue.h:147
#2  0x0000000000f57d1e in Priority_queue<uchar*, std::vector<uchar*, Malloc_allocator<uchar*> >, <unnamed>::Mem_compare>::update_top(void) (this=0x7ffff0115650)
    at /root/mysql5.7.14/percona-server-5.7.14-7/include/priority_queue.h:354
#3  0x0000000000f57814 in Bounded_queue<uchar*, uchar*, Sort_param, <unnamed>::Mem_compare>::push(uchar *) (this=0x7ffff0115650, element=0x7fff309166a0 "o")
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/bounded_queue.h:106
#4  0x0000000000f52da7 in find_all_keys(Sort_param *, QEP_TAB *, Filesort_info *, IO_CACHE *, IO_CACHE *, Bounded_queue<uchar*, uchar*, Sort_param, <unnamed>::Mem_compare> *, ha_rows *) (param=0x7ffff01154c0, qep_tab=0x7fff309268e8, fs_info=0x7ffff0115550, chunk_file=0x7ffff0115200, tempfile=0x7ffff0115360, pq=0x7ffff0115650, 
    found_rows=0x7ffff0115898) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/filesort.cc:1013
#5  0x0000000000f51165 in filesort (thd=0x7fff30000bc0, filesort=0x7fff30926bd8, sort_positions=false, examined_rows=0x7ffff01158a0, found_rows=0x7ffff0115898, 
    returned_rows=0x7ffff0115890) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/filesort.cc:425

附：如果需要算法实现可参见原文:
https://www.jianshu.com/p/8c2154872f83


对本文有任何疑问可扫码添加原文作者微信

640?wx_fmt=jpeg


640.gif?


加入知数堂

挑战40万+年薪！



640?640?640?640?


知数堂

叶金荣与吴炳锡联合打造

领跑IT精英培训

行业资深专家强强联合，倾心定制

MySQL实战/MySQL优化/MongoDB/

Python/ SQL优化/Hadoop+ELK

数门精品课程

“阅读原文”可获更多正课试听视频

密码：hg3h

紧随技术发展趋势，定期优化培训教案

融入大量生产案例，贴合企业一线需求

社群陪伴学习，一次报名，可学1年

DBA、开发工程师必修课

上千位学员已华丽转身，薪资翻番，职位提升

改变已悄然发生，你还在等什么？

640.png?


640?wx_fmt=gif 扫码加入QQ技术交流群

MySQL 8.0|MGR研究院-ZST

（QQ群号：650149401）    

640?wx_fmt=jpeg

老叶茶馆_
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MySql那些事儿（六）：你知道order by是怎么排序的吗？
Simoss的博客
12-02 257
作者：阿茂 从这一片开始我们就说一下平时是遇到的问题以及其原理解析，看到标题有没有朋友遇到过sql加了order by速度很慢的呢？下面我们来看了例子，建表语句入下： CREATE TABLE `t` ( `id` int(11) NOT NULL, `city` varchar(16) NOT NULL, `name` varchar(16) NOT NULL, `age` in...
编码踩坑——MySQL order by&limit顺序不一致 / 堆排序 / 排序稳定性
娜娜米的博客
03-12 3408
本篇介绍一个MySQL下SQL查询语句同时包含order by和limit出现的一个问题及原因，其中涉及的知识点包括 ：MySQL对limit的优化、MySQL的order排序、优先级队列和堆排序、堆排序的不稳定性；
MySQL语句介绍
最新发布
m0_74087268的博客
06-22 1159
启动mysql服务命令mysql -u root -P 3306;create database db_name;show databases;show create database db_name;默认的字符集为utf8，但也可以进行更换create database db_name character set GBK;show character set;alter database ab_name [alter_specification];比如说修改数据库的字符集及校验规则alter databa
MYSQL 排序ORDER BY与分页LIMIT数据错乱
RO_YI的博客
05-19 654
ORDER BY的字段重复时，使用LIMIT取值，随机返回数据。 解决方法： ORDER BY 后添加唯一列排序
order by 连用limit分页不稳定
weixin_44235601的博客
04-02 163
如果order by后面的条件相同，就会导致mysql随机排序，出现数据错误； 可使用order by id或order by gmt_create,id
记一次mysql排序语句order by加了limit导致结果不一致
qq_59372626的博客
09-04 186
使用order by 时，在不影响需求的场景下最好跟一个唯一索引。新建一个表user，字段为id、name。两条语句返回结果不一致。
踩坑笔记 MySQL分页排序查询（Order by limit）导致数据丢失和重复
laker的博客
10-03 2089
在执行查询时，MySQL会根据查询优化器的决策来确定数据的检索顺序，如果没有明确的排序规则，结果集的顺序可能会随机，这可能会让人感到困惑。分页查询排序后的数据，是一个非常常见的业务场景；但当使用不唯一的字段排序时，分两页查询的数据可能出现数据重复和丢失的错觉。这个优先队列的本质和Java中的堆一样的，可以根据limit的条数维护一个堆。以后的版本都会有，严格的说这并不算一个问题，MySQL官方对。如果没有唯一字段，联合索引构成的联合唯一索引也行。一张很屌的图，来自牛逼的 ALEX XU。
Mysql排序和分页(order by&limit)及存在的坑
12-14
总之，`ORDER BY`和`LIMIT`是MySQL中用于数据排序和分页的关键工具，理解它们的用法并注意性能优化，能有效提升数据库查询的效率和用户体验。在实际应用中，应结合具体场景选择合适的排序和分页策略，以达到最佳效果...
MySQL查询优化:连接查询排序limit(join、order by、limit语句)介绍
09-10
在MySQL查询优化中，连接查询（join）与排序（order by）和限制返回结果的数量（limit）是常见的操作，但当它们结合在一起时，可能会导致性能下降。这个问题在标题和描述中已经阐述得很清楚，主要涉及到如何高效地...
MySQL 通过索引优化含ORDER BY的语句
12-15
MySQL数据库在处理含`ORDER BY`的SQL语句时，索引优化是非常关键的一环，因为这直接影响到查询性能。以下是一些关于如何利用索引来优化`ORDER BY`语句的知识点： 1. **合理创建索引**：索引可以显著提高数据读取...
MySQL中Union子句不支持order by的解决方法
09-10
在MySQL中，`UNION` 子句用于合并两个或多个`SELECT`语句的结果集，但是它并不直接支持在每个`SELECT`语句后直接跟`ORDER BY`子句来对合并后的结果进行排序。这是因为`UNION`操作会先进行数据合并，然后再去除重复的...
MySQL ORDER BY 的实现分析
09-11
MySQL中的`ORDER BY`语句用于对查询结果进行排序，其内部实现主要涉及两种方法：利用有序索引和内存中的排序算法。 1. **利用有序索引进行排序**： 当`ORDER BY`的条件与查询中使用的索引键完全匹配，并且查询计划...
Mysql 排序Order by与分页limit结合的数据异常问题
沛哥儿的专栏
04-13 1673
前言 在使用order by 进行排序的时候，使用LambdaQueryWrapper也是杠杠的。使用orderByDesc方法可以很方便的进行多字段排序。 问题 但是使用分页排序的时候，Limit出来的数据，居然会重复。 刚开始以为使用了多个字段进行order by ，导致查询结果不正常。 出于对自己技术的不信任，特意跑到mybati-plus官网查了文档，发现一切都是正常的。 那么就是mysql的问题了。 开启sql日志输出，发现sql正常，使用查询的时候，发现数据重叠了。 第一页数..
mysql 排序方法
waiwai021的博客
09-20 221
1、order by id  asc    按照id升序 eg: select  id  from users  order by id asc 2、order by id desc  按照id降序  eg: select  id  from users  order by id desc 3、order by field(name,'Suzi','Ben','Henry'
MySQL中order by与limit结合使用导致数据错乱问题
经典
04-12 2778
MySQL中order by与limit结合使用导致数据错乱问题 最近在项目中需要调用微服务获取数据集合，而在对方微服务中使用了limit对数据进行了分页处理，但是在limit之前使用order by进行了排序，然后当查询前10条数据的时候结果显示正常，当查询第11-20或者21-30条的数据的时候，会发生数据错乱的现象。 sql语句： order by create_date desc limit 0, 10 sql语句： order by create_date desc limit 10, 10
mysql 排序速度_MySQL排序速度慢而且可能不稳定
weixin_34379608的博客
01-19 1990
一、具体现象有一个功能，按照算法得出的权重值，分页展示一批列表数据，权重值越大越靠前。研发同学反馈查询速度慢且排序不稳定。排序不稳定的具体现象，有不少记录存在相同权重值，某条记录(假设id=100)第一页出现了，翻到第二页可能还有它(采用的limit控制哪一页)。第1页数据 第2页数据 一个主表A，左连接两个表B、C，根据C的权重字段排序。具体SQL如下 二、问题分析查看SQL语句的执行计划(EX...
数据库orderby添加limit关键字前后，结果不稳定现象
tang_world的博客
10-14 1072
综上所述，这是一个查询优化器做的优化，不要关系这个优化，再order by 其他的唯一键列，来让limit时的顺序固定，即orderby a，a值相同的列的顺序固定按照其他唯一列排序，即可达到要求。
Mysql使用order by排序，顺序错乱，按照id排序也是乱序。
清风思雨的博客
08-17 3337
我当时用的docker里面的mysql8，本以为是docker里面的和本地下载的mysql8不一样，因为docker的原因，比本地的mysql占用内存小了近2/3，但是，后续发现，原因不在docker！我的原因是用本地的Navicat导入txt数据文件时，导入的int类型全变为了varchar，并且varchar类型都为默认值255，主键也没有了，更别说主键的int自增。由此可见，每次导入txt文件后，都应该根据原表重新修改表属性，好在数据都直接导入，不需要再次添加。设置为数值类型即可。...
数据库优化-排序篇 (order by)
学习真香
02-27 3618
数据库优化-排序篇 (order by) 背景 日常开发工作中, 经常使用order by对结果集进行排序, 但是对其原理和具体实现可能不是很了解. 这样无法进行有效的分析和针对性优化. 因此, 我写下本篇文章介绍一下 order by的基本原理和一些工作中常见的问题. 带着问题去学习, 效率会更高, 更有趣. 数据准备 因为在工作中使用pg多一些, 所以文中的数据库选择了 PostgreSQL 11.14 64-bit 造一些测试数据, 可以参考: pg 快速造1000w测试数据 CREATE TABLE
mysql中groupby order by limit 先后顺序
07-27
在MySQL中，GROUP BY、ORDER BY和LIMIT这三个关键字的顺序是有一定规定的。一般来说，它们的顺序应该是先使用GROUP BY进行分组，然后使用HAVING进行筛选，接着使用ORDER BY进行排序，最后使用LIMIT进行结果限制。 具体来说，在查询中，应该按照以下顺序使用这三个关键字： 1. 使用GROUP BY对结果进行分组，以便按照某个字段或表达式进行聚合操作。 2. 使用HAVING对分组后的结果进行筛选，只保留满足条件的分组。 3. 使用ORDER BY对筛选后的结果进行排序，可以按照一个或多个字段进行升序或降序排序。 4. 最后使用LIMIT对排序后的结果进行限制，只返回指定数量的结果。 所以，在你提供的引用中，需求四的查询语句的顺序是正确的，先使用GROUP BY进行分组，然后使用HAVING进行筛选，接着使用ORDER BY进行排序，最后使用LIMIT进行结果限制。而需求三的查询语句则没有使用HAVING进行筛选，所以它的顺序是不正确的。 总结起来，正确的顺序是：GROUP BY -> HAVING -> ORDER BY -> LIMIT。 #### 引用[.reference_title] - *1* *2* *3* [mysql中 join 、group by、having、order by、limit 执行顺序](https://blog.csdn.net/weixin_43689776/article/details/101107378)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^control_2,239^v3^insert_chatgpt"}} ] [.reference_item] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值