|
作者丨Julia Evans 譯者丨無明 很多 SQL 查詢都是以 SELECT 開始的。不過，最近我跟別人解釋什么是窗口函數(shù)，我在網(wǎng)上搜索”是否可以對窗口函數(shù)返回的結(jié)果進(jìn)行過濾“這個問題，得出的結(jié)論是”窗口函數(shù)必須在 WHERE 和 GROUP BY 之后，所以不能”。于是我又想到了另一個問題：SQL 查詢的執(zhí)行順序是怎樣的？ 好像這個問題應(yīng)該很好回答，畢竟自己已經(jīng)寫了上萬個 SQL 查詢了，有一些還很復(fù)雜。但事實(shí)是，我仍然很難確切地說出它的順序是怎樣的。 于是我研究了一下，發(fā)現(xiàn)順序大概是這樣的。SELECT 并不是最先執(zhí)行的，而是在第五個。 這張圖與 SQL 查詢的語義有關(guān)，讓你知道一個查詢會返回什么，并回答了以下這些問題：
但數(shù)據(jù)庫引擎并不一定嚴(yán)格按照這個順序執(zhí)行 SQL 查詢，因?yàn)闉榱烁斓貓?zhí)行查詢，它們會做出一些優(yōu)化，這些問題會在以后的文章中解釋。 所以：
有很多 SQL 實(shí)現(xiàn)允許你使用這樣的語法： SELECT CONCAT(first_name, ' ', last_name) AS full_name, count(*)FROM tableGROUP BY full_name從這個語句來看，好像 GROUP BY 是在 SELECT 之后執(zhí)行的，因?yàn)樗昧?SELECT 中的一個別名。但實(shí)際上不一定要這樣，數(shù)據(jù)庫引擎可以把查詢重寫成這樣：
這樣 GROUP BY 仍然先執(zhí)行。 數(shù)據(jù)庫引擎還會做一系列檢查，確保 SELECT 和 GROUP BY 中的東西是有效的，所以會在生成執(zhí)行計劃之前對查詢做一次整體檢查。 在實(shí)際當(dāng)中，數(shù)據(jù)庫不一定會按照 JOIN、WHERE、GROUP BY 的順序來執(zhí)行查詢，因?yàn)樗鼈儠M(jìn)行一系列優(yōu)化，把執(zhí)行順序打亂，從而讓查詢執(zhí)行得更快，只要不改變查詢結(jié)果。 這個查詢說明了為什么需要以不同的順序執(zhí)行查詢： SELECT * FROMowners LEFT JOIN cats ON owners.id = cats.ownerWHERE cats.name = 'mr darcy'如果只需要找出名字叫“mr darcy”的貓，那就沒必要對兩張表的所有數(shù)據(jù)執(zhí)行左連接，在連接之前先進(jìn)行過濾，這樣查詢會快得多，而且對于這個查詢來說，先執(zhí)行過濾并不會改變查詢結(jié)果。 數(shù)據(jù)庫引擎還會做出其他很多優(yōu)化，按照不同的順序執(zhí)行查詢，不過我并不是這方面的專家，所以這里就不多說了。 LINQ（C# 和 VB.NET 中的查詢語法）是按照 FROM…WHERE…SELECT 的順序來的。這里有一個 LINQ 查詢例子：
pandas 中的查詢也基本上是這樣的，不過你不一定要按照這個順序。我通常會像下面這樣寫 pandas 代碼： df = thing1.join(thing2) # JOINdf = df[df.created_at > 1000] # WHEREdf = df.groupby('something', num_yes = ('yes', 'sum')) # GROUP BYdf = df[df.num_yes > 2] # HAVING, 對 GROUP BY 結(jié)果進(jìn)行過濾df = df[['num_yes', 'something1', 'something']] # SELECT, 選擇要顯示的列df.sort_values('sometthing', ascending=True)[:30] # ORDER BY 和 LIMITdf[:30]這樣寫并不是因?yàn)?pandas 規(guī)定了這些規(guī)則，而是按照 JOIN/WHERE/GROUP BY/HAVING 這樣的順序來寫代碼會更有意義些。不過我經(jīng)常會先寫 WHERE 來改進(jìn)性能，而且我想大多數(shù)數(shù)據(jù)庫引擎也會這么做。 R 語言里的 dplyr 也允許開發(fā)人員使用不同的語法編寫 SQL 查詢語句，用來查詢 Postgre、MySQL 和 SQLite。 |
|
|
來自： 昵稱QvKmxOqV > 《文件夾1》
