摘要：這一次，返回的結(jié)果則是李雷藍(lán)色生死戀李雷這個殺手不太冷韓梅梅冰與火之歌韓梅梅天國的階梯韓梅梅阿甘正傳安華暴走漫畫可以發(fā)現(xiàn)，這一次，我們得到的結(jié)果就是按照條件參數(shù)列表李雷韓梅梅安華進(jìn)行排序后得到了。

我們都非常習(xí)慣通過 MySQL 的 IN 函數(shù)來查詢特定集合的數(shù)據(jù)，比如為了在 books 表中找出李雷、韓梅梅和安華寫的書，我們可以有如下的 SQL：

SELECT * FROM books WHERE `books`.`author` IN ("李雷","韓梅梅","安華");

注意: 可以通過 SQL Fiddle 查看以上示例。

數(shù)據(jù)庫返回如下結(jié)果：

雖然這樣確實能夠返回所有李雷、韓梅梅和安華寫過的書，但是返回的數(shù)據(jù)的排序方式是默認(rèn)按照數(shù)據(jù)在數(shù)據(jù)庫中的存儲順序，假如我們需要的返回結(jié)果是同時按照 IN 查詢條件里邊的參數(shù)順序來排序呢？這個時候我們就需要利用到 MySQL FIELD 這個函數(shù)了，F(xiàn)IELD 函數(shù)本來是 MySQL 提供用來查詢某一個字符串在給定字符串元組中的索引位置的，比如這個官方例子：

SELECT FIELD("ej", "Hej", "ej", "Heja", "hej", "foo"); # -> 2

如果將其應(yīng)用在 ORDER BY 排序條件中，就可以根據(jù)指定字段的值在給定參數(shù)列表中的索引數(shù)值，進(jìn)而將查詢結(jié)果按照參數(shù)列表排序了：

SELECT * FROM books WHERE `books`.`author` IN ("李雷","韓梅梅","安華") ORDER BY FIELD(author, "李雷","韓梅梅","安華");

注意： 可以通過SQL Fiddle查看以上示例。

這一次，返回的結(jié)果則是：

可以發(fā)現(xiàn)，這一次，我們得到的結(jié)果就是按照條件參數(shù)列表 "李雷","韓梅梅","安華" 進(jìn)行排序后得到了。

本文提到的 FIELD 函數(shù)，畢竟只是 MySQL 數(shù)據(jù)庫內(nèi)置提供的一種函數(shù)，除非你非常明確你的項目就是只用 MySQL 數(shù)據(jù)庫，否則，你的 SQL 代碼在未來遷移到其他數(shù)據(jù)庫的過程中就會遇到語法兼容性問題（只是 PostgreSQL 數(shù)據(jù)庫不支持 FIELD）。

我們都知道，數(shù)據(jù)庫在進(jìn)行 ORDER BY 排序的時候，除非它是按照某個已經(jīng)存在索引的鍵的值進(jìn)行排序，否則數(shù)據(jù)庫則需要通過計算 ORDER BY 中表達(dá)式的值并且按照查詢結(jié)果建立新的臨時表，這個過程會帶來額外的時間開銷跟內(nèi)存開銷，對數(shù)據(jù)庫本身就是一種性能負(fù)擔(dān)。這樣的方式在單一數(shù)據(jù)庫多個數(shù)據(jù)庫客戶端連接的時候，可能對數(shù)據(jù)庫造成太大負(fù)擔(dān)。

盡管使用 FIELD 函數(shù)可能帶來兼容性以及性能方面的隱患，但是 FIELD 的使用并非全是有損之處。

比如在與 Ruby 的 active_record 結(jié)合時，這種通過數(shù)據(jù)庫直接完成排序等 SQL 語句可以方便我們構(gòu)建 ActiveRecord::Relation 對象，因為我們不再需要先將查詢結(jié)果集從內(nèi)存中轉(zhuǎn)為數(shù)組排序，再進(jìn)行二次查詢，可以幫助我們減少 N+1 查詢問題，后者也是常見的影響數(shù)據(jù)庫服務(wù)器性能的現(xiàn)象之一。除此之外，這樣的寫法也可以有效地幫助我們簡化代碼，保持代碼簡潔。

但是在不需要對數(shù)據(jù)進(jìn)行二次查詢或者查詢數(shù)據(jù)量太大的情況下，我反而建議可以通過 Ruby 的 Array#sort_by 方法對數(shù)據(jù)進(jìn)行排序，這樣的話，排序的任務(wù)就轉(zhuǎn)移給了客戶端代碼，排序任務(wù)的壓力就自然分散，減輕了服務(wù)器端的壓力。

FIELD 函數(shù)結(jié)合 ORDER BY 可以幫助我們將查詢結(jié)果集按照參數(shù)列表順序返回；

FIELD 函數(shù)結(jié)合 ORDER BY 的方式可以幫助我們在數(shù)據(jù)庫層面完成排序，簡化了業(yè)務(wù)代碼邏輯；

FIELD 函數(shù)結(jié)合 ORDER BY 可能帶來 SQL 兼容性以及性能方面的問題；

在確認(rèn)項目數(shù)據(jù)庫不大可能為 MySQL
之外的數(shù)據(jù)庫的前提下，查詢數(shù)據(jù)量少或者需要保持業(yè)務(wù)代碼簡潔的場景下，我建議可以采用 FIELD 函數(shù)排序；而在數(shù)據(jù)量龐大的情況下，或者不大可能出現(xiàn)大量 N+1 查詢的情況下，我建議可以采用先在數(shù)據(jù)庫中查詢數(shù)據(jù)集（只查詢 IN 條件，不排序）再到內(nèi)存中通過業(yè)務(wù)代碼排序(比如 Ruby 的 Array#sort_by)的方式。