- 景象与问题
ORDER BY排序后，用LIMIT取前几条，发现返回的后果集的程序与预期的不一样。
上面是我遇到的问题：
能够看到，带LIMIT与不带LIMIT的后果与我预期的不一样，而且“很不堪设想”，真是百思不得其解。
起初百度了一下，如果order by的列有雷同的值时，mysql会随机选取这些行，为了保障每次都返回的程序统一能够额定减少一个排序字段（比方：id），用两个字段来尽可能减少反复的概率。
于是，改成 order by status, id;
问题尽管是解决了，但还是看看官网文档上怎么说的吧！
- 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中蕴含附加列，以使程序具备确定性。例如：
- 小结
1、如果你只须要后果集中的某几行，那么倡议应用limit。这样这样的话能够防止抓取全副后果集，而后再抛弃那些你不要的行。
2、对于order by查问，带或者不带limit可能返回行的程序是不一样的。
3、如果limit row_count 与 order by 一起应用，那么在找到第一个row_count就进行排序，间接返回。
4、如果order by列有雷同的值，那么MySQL能够自在地以任何程序返回这些行。换言之，只有order by列的值不反复，就能够保障返回的程序。
5、能够在order by子句中蕴含附加列，以使程序具备确定性。
https://cloud.tencent.com/dev...