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.  小结

1、如果你只需要结果集中的某几行，那么建议使用limit。这样这样的话可以避免抓取全部结果集，然后再丢弃那些你不要的行。

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

3、如果limit row_count 与 order by 一起使用，那么在找到第一个row_count就停止排序，直接返回。

4、如果order by列有相同的值，那么mysql可以*地以任何顺序返回这些行。换言之，只要order by列的值不重复，就可以保证返回的顺序。

5、可以在order by子句中包含附加列，以使顺序具有确定性。

4.  文档