MySQL中ORDER BY与LIMIT一块儿使用（有坑）

1.  现象与问题

ORDER BY排序后，用LIMIT取前几条，发现返回的结果集的顺序与预期的不同

下面是我遇到的问题：

能够看到，带LIMIT与不带LIMIT的结果与我预期的不同，并且“很难以想象”，真是百思不得其解

后来百度了一下，若是order by的列有相同的值时，mysql会随机选取这些行，为了保证每次都返回的顺序一致能够额外增长一个排序字段（好比：id），用两个字段来尽量减小重复的几率

因而，改为 order by status, id;

问题虽然是解决了，但仍是看看官方文档上怎么说的吧！

2.  LIMIT查询优化

——摘自“LIMIT查询优化”

若是你只须要结果集中的指定数量的行，那么请在查询中使用LIMIT子句，而不是抓取整个结果集并丢弃剩下那些你不要的数据。

MySQL有时会优化一个包含LIMIT子句而且没有HAVING子句的查询：

• MySQL一般更愿意执行全表扫描，可是若是你用LIMIT只查询几行记录的话，MySQL在某些状况下可能会使用索引。
• 若是你将LIMIT row_count子句与ORDER BY子句组合在一块儿使用的话，MySQL会在找到排序结果的第一个row_count行后当即中止排序，而不是对整个结果进行排序。若是使用索引来完成排序，这将很是快。若是必须执行文件排序，则在找到第一个row_count行以前，选择全部与查询匹配但不包括LIMIT子句的行，并对其中大部分或全部行进行排序。一旦找到第一个row_count以后，MySQL不会对结果集的任何剩余部分进行排序。这种行为的一种表现形式是，一个ORDER BY查询带或者不带LIMIT可能返回行的顺序是不同的。
• 若是LIMIT row_count与DISTINCT一块儿使用，一旦找到row_count唯一的行，MySQL就会中止。
• LIMIT 0 能够快速返回一个空的结果集，这是用来检测一个查询是否有效的一种颇有用的方法。
• 若是服务器使用临时表来解析查询，它将使用LIMIT row_count子句来计算须要多少空间。
• 若是ORDER BY不走索引，并且后面还带了LIMIT的话，那么优化器可能能够避免用一个合并文件，并使用内存中的filesort操做对内存中的行进行排序。

若是ORDER BY列有多行具备相同的值，服务器能够自由地以任何顺序返回这些行，而且根据整体执行计划可能以不一样的方式返回。换句话说，这些行的排序顺序对于无序列是不肯定的。

影响执行计划的一个因素是LIMIT，所以对于一个ORDER BY查询而言，带与不带LIMIT返回的行的顺序多是不同的。

看下面的例子：

包含LIMIT可能会影响每个category行的顺序。例如：

若是你须要确保不管带不带LIMIT都要以相同的顺序返回，那么你能够在ORDER BY中包含附加列，以使顺序具备肯定性。例如：

3.  小结

一、若是你只须要结果集中的某几行，那么建议使用limit。这样这样的话能够避免抓取所有结果集，而后再丢弃那些你不要的行。

二、对于order by查询，带或者不带limit可能返回行的顺序是不同的。

三、若是limit row_count 与 order by 一块儿使用，那么在找到第一个row_count就中止排序，直接返回。

四、若是order by列有相同的值，那么MySQL能够自由地以任何顺序返回这些行。换言之，只要order by列的值不重复，就能够保证返回的顺序。

五、能够在order by子句中包含附加列，以使顺序具备肯定性。

4.  文档

https://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html

https://dev.mysql.com/doc/refman/5.7/en/

https://dev.mysql.com/doc/