[[321167]]

經常聽到這樣的事情，某個程序員在后臺執行個Sql語句，然后把線上服務都拖垮了。有些人會認為，Sql的執行性能是DBA的事情，但是隨著互聯網的發展，對開發的要求也越來越高，特別是一些小團隊，巴不得人人都是全棧工程師。今天我們來聊一聊Mysql中的排序，Order By。

在我們執行Mysql的Explain語句的時候，經常會看到這樣的一個Using filesort。那么，Mysql的排序是在內存里面進行的，還是在磁盤里面進行的呢?假如我們是Mysql的設計者，我們會怎么做呢?首先，在內存里面來進行排序的速度，肯定是遠遠大于在磁盤中的。但是內存的資源畢竟有限，假如我們掃描到足夠多的行，這個時候可能數據的大小已經超過內存，想在內存中進行排序是很困難的，這個時候我們只能夠使用磁盤來進行排序了。

沒錯，Mysql也是這么設計的，Mysql有一個配置項，sort_buffer_size，如果我們Select到的數據量小于這個數，那么就會將數據在內存中進行排序，否則，Mysql就會把數據拆成很多個臨時文件，每個臨時文件的大小都會小于sort_buffer_size。也就是說，如果sort_buffer_size越小，拆分的臨時文件就會越多，這也是為什么我們選來當存儲的機器內存也要盡量大的原因。Mysql排序了多個臨時文件之后，最后在做一次歸并排序，就可以將所有記錄排完了。

相信大家下面這樣的話，如果你的數據庫的列數比較多，那么盡量地不要使用Select * 而是需要什么字段就只取什么字段，在數據庫的排序中尤為如此。假如我們的數據列數特別多，滿足條件的行數也多，這個時候，Mysql就不得不用更極端的排序算法進行排序，每一行數據，都只取主鍵id跟排序的字段。然后進行排序，最后，再取要滿足條件的結果回表查詢其他字段，然后返回結果。相對于原有上面的方案，這種Rowid的排序方式多了一次回表，所以查詢效率大打折扣。

那么，我們有什么辦法可以進行排序的優化呢?我們都知道，Innodb的索引實際上是一顆多叉排序樹，那么假如我們能夠在已有的排序樹上取得結果，豈不美哉?!所以，如果我們要查詢已經要排序的字段全都在已有的索引上，并且滿足最左前綴原則，那么，我們就可以減少一次回表，從而大大提升效率。那么，如果判斷你的Sql語句滿足了這種優化呢?如果你的語句中含有OrderBy，但是Explain的結果卻只有UseIndex，說明命中了索引覆蓋。

當然，并不是所有的查詢都要命中索引覆蓋的，前面我們也提到了，維護索引是由代價的，還是需要具體問題具體分析。