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. 文件
https://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html
https://dev.mysql.com/doc/refman/5.7/en/