查詢不像程序那樣執行。他們不是做第1步然後第2步的程序。相反,它們是關於你想要的結果的聲明性陳述。在大多數現代RDBMS中,任何給定的查詢都可以通過許多不同的查詢計劃來執行。通常,創建不同的查詢計劃,然後評估哪個計劃運行得最快。在創建一系列查詢計劃時,它會考慮應首先評估哪些條件,應該在評估條件之前或之後進行連接,以及嘗試確定哪些條件會被禁食(基於其對於表格大小並猜測表格的百分比將包含在給定條件下)。他們中的許多人也會查看以前的結果,以便爲未來的決策提供有關其近似值出錯的信息。
最有可能的,在任何現代RDBMS,這兩個查詢會產生相同的一組查詢計劃,因此同樣的選擇將作出,導致相同的查詢計劃的兩個查詢被執行。根據您正在使用的RDBMS,通常可以使用工具查看爲給定查詢選擇的特定查詢計劃,因此您可以使用該工具針對特定數據庫上的兩個特定查詢絕對回答問題。
現在,他說,我要指出,這並不等於說「它總是會產生相同的數據相同的答案任意兩個查詢將始終以相同的時間量。」有可能編寫非常糟糕的查詢,主要是通過不必要的複雜性,並且不能保證查詢規劃者會意識到您已經過度了。它可能會捕獲簡單的情況。因此,例如:
SELECT * FROM student_tbl A, result_tbl B WHERE
A.student_name = B.student_name AND
A.student_name = 'xyz' AND
B.student_name = A.student_name
也可能會產生相同的查詢計劃。而這也可能:
SELECT * FROM student_tbl A, result_tbl B WHERE
A.student_name = B.student_name AND
A.student_name = 'xyz' AND
B.student_name = 'xyz'
但是,如果你做的東西非常複雜的像
(SELECT * FROM student_tbl A, result_tbl B WHERE
A.student_name = B.student_name AND
A.student_name = 'xyz')
UNION
(SELECT * FROM student_tbl A, result_tbl B WHERE
A.student_name = B.student_name AND
B.student_name = 'xyz')
INTERSECT
(SELECT * FROM student_tbl A, result_tbl B WHERE
A.student_name = 'xyz')
它可以運行更復雜的查詢計劃。 (即使這個完全不必要的複雜查詢會產生與其他兩個相同的結果(假設沒有NULL))。
因此,優化器不是無所不知的,但它們傾向於認識到X和Y與Y和X是同一事物,並且A = B和B = C與A = C和A = B並針對這些情況進行相應調整。他們實際上做了各種轉換,試圖找到最好的查詢,並且通常很擅長查找它。可以重寫查詢計劃程序的決策,但只有在確定有更好的方法來執行查詢並且數據更改不可能改變查詢時才能完成。
無論可能存在的差異(如果有的話)都可能是實現特定的。對我而言,這屬於「微觀優化」類別。爲什麼不設置一個測試用例並在測試結果非常重要時進行測量? – spender
@spender我*猜*這是作業。可能是錯的。我只是因爲再次錯誤而已......這已經過去了幾秒鐘! ;) –
@andrew barber我剛纔在我的問題中給了一個簡單的例子。實際上他們有2個表格,數據量很大。 – user1085296