关于mysql:切记MySQL中ORDER-BY与LIMIT-不要一起用有大坑

50次阅读

共计 1446 个字符，预计需要花费 4 分钟才能阅读完成。

景象与问题
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 中蕴含附加列，以使程序具备确定性。例如：