[[321167]]

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

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

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

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

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

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