?查詢優(yōu)化器內核剖析第一篇

?

查詢優(yōu)化器內核剖析第一篇

查詢優(yōu)化器內核剖析第二篇：產(chǎn)生候選執(zhí)行計劃&執(zhí)行計劃成本估算

查詢優(yōu)化器內核剖析第三篇：查詢的執(zhí)行與計劃的緩存 & Hint提示

查詢優(yōu)化器內核剖析第四篇：從一個實例看執(zhí)行計劃

查詢優(yōu)化器內核剖析第五篇：進一步的了解執(zhí)行計劃

查詢優(yōu)化器內核剖析第六篇：談談Join的順序問題，糾正江湖偏方

查詢優(yōu)化器內核剖析第七篇：執(zhí)行引擎之數(shù)據(jù)訪問操作---Scan

查詢優(yōu)化器內核剖析第八篇：執(zhí)行引擎之數(shù)據(jù)訪問操作---Seek與Lookup

查詢優(yōu)化器內核剖析第九篇：執(zhí)行引擎之數(shù)據(jù)訪問操作---Bookmark Lookup

查詢優(yōu)化器內核剖析第十篇：執(zhí)行引擎之數(shù)據(jù)訪問操作- Aggregations(聚合)

?

??? SQL Server的查詢優(yōu)化器是一個基于成本的優(yōu)化器。它為一個給定的查詢分析出很多的候選的查詢計劃，并且估算每個候選計劃的成本，從而選擇一個成本最低的計劃進行執(zhí)行。實際上，因為查詢優(yōu)化器不可能對每一個產(chǎn)生的候選計劃進行優(yōu)化，所以查詢優(yōu)化器會在優(yōu)化時間和查詢計劃的質量之間進行一個平衡，盡可能的選擇一個“最優(yōu)”的計劃。

?

??? 所以，查詢優(yōu)化器成為SQL Server中最重要的一個組件，并且影響著SQL Server的性能。選擇正確或錯誤的執(zhí)行計劃意味著查詢執(zhí)行時間可能存在著毫秒的，幾分鐘，甚至幾個小時之間的差異。

?

??? 了解查詢優(yōu)化的內部機制，可以幫助DBA和開發(fā)人員能夠編寫更好的查詢，或者給查詢優(yōu)化器提供信息使得它可以產(chǎn)生有效的執(zhí)行計劃。本系列文章講述的查詢優(yōu)化器的內部運作的知識，此外，還會告訴你如何使用查詢優(yōu)化器的相關信息進行性能診斷。

?

???? 下面，我們首先來看看：查詢優(yōu)化器是如何工作的。

?

???? 在SQL Server數(shù)據(jù)庫引擎的核心是兩個主要部分組成：存儲引擎和查詢處理器（也被稱為關系引擎）。存儲引擎負責在磁盤和內存之間以最優(yōu)化的方式讀取數(shù)據(jù)，同時維護數(shù)據(jù)的完整性。查詢處理器，顧名思義，接受提交給SQL Server所有的查詢，并且為產(chǎn)生他們的最佳執(zhí)行計劃，然后執(zhí)行該計劃，并提供所需的結果。

?

??? 我們將查詢以T-SQL的形式提交給SQL Server。因為SQL語句是一個高層抽象的聲明性的語言，它僅僅只是定義了要從數(shù)據(jù)庫中獲取什么樣的數(shù)據(jù)，而沒有告訴如何去獲取這些數(shù)據(jù)（或者說，沒有定義獲取數(shù)據(jù)的方法和步驟）。所以，對于SQL Server所接受到的每一個查詢，查詢處理器的首要任務就是產(chǎn)生一個計劃，這個計劃就描述了如何去執(zhí)行查詢，之后就由存儲引擎去執(zhí)行這個計劃了。

?

??? 為了確保已經(jīng)達到在查詢處理器認為是最好的計劃執(zhí)行查詢，查詢處理器執(zhí)行不同的步驟，整個查詢處理過程如圖所示：

?

?

??? 當然，上面的圖只是一個最簡單的示例圖，下面，給大家看另外一個圖，體會一下一個查詢處理的過程：

?

???????我們在后續(xù)的文章中會看到每一個步驟的詳細講解與應用，下面我們就簡單的介紹圖中的一些步驟（為了簡單起見，我們以第一幅圖為例子）

Parsing 和Binding（解析與綁定）：在一個查詢提交給了數(shù)據(jù)庫之后，首先就要被進行語法的解析，如果這個查詢的語法是沒有問題的，那么這個Parsing過程的輸入結果就是一個邏輯樹，在這個邏輯樹種每一個節(jié)點都表示了這個查詢進行的每個操作，例如讀取某個表，進行inner join等。

??????? 下面，給大家看一個邏輯樹的例子，對于下面的查詢：

?

?????????????? 產(chǎn)生的邏輯樹如下：

?

?????????????? 這個過程就是編譯原理的一個文法詞法的解析。

?????????????? 談完了Parsing，之后的操作就是Binding了，這個操作現(xiàn)在改名字為Algebrizer。這個操作主要就是檢查解析產(chǎn)生的邏輯樹中的對象是否存在，例如Customer是否是數(shù)據(jù)庫中的表，CustomerID字段是否在Customer表中等。

?????????????? 經(jīng)過了這個Binding之后，就會產(chǎn)生另外一個樹形的數(shù)據(jù)結構，傳遞給下一個步驟。

???? 2. 查詢優(yōu)化。這個過程主要是使用上述過程中的Algebrizer Tree進行優(yōu)化的處理過程，我們這里大體的可以將這個優(yōu)化的處理過程分為兩個步驟：

?

???????? a. 產(chǎn)生執(zhí)行計劃。在這個過程中，查詢優(yōu)化器會使用之前的樹，產(chǎn)生執(zhí)行計劃。這個過程主要是將樹上的邏輯操作轉換為物理操作（其實就是存儲引擎可以調用的方法，這些方法就是實實在在的去讀取數(shù)據(jù)的）。

?

???????? b.估算每個執(zhí)行計劃的成本。一個邏輯操作可以有很多的物理操作與其對應，而每個物理操作的成本不一樣，同時，也沒用所謂的“什么物理操作比其他的物理操作更優(yōu)” ，一切視情況可認定。在這個過程中產(chǎn)生很多的候選執(zhí)行計劃，并且查詢優(yōu)化器會綜合考慮很多的情況，選擇一個它認為“比較優(yōu)”的計劃，傳遞給存儲引擎。

?

???? 3. 查詢的執(zhí)行與計劃的緩存。這個過程比較簡單了，主要是存儲引擎去執(zhí)行執(zhí)行計劃，同時為了避免相類似的SQL查詢重新編譯，使用過的執(zhí)行計劃會被緩存在計劃緩存池中。

?

??? 基本是，我們可以看出，查詢優(yōu)化的過程就是一個將邏輯操作映射為物理操作的過程。

?? 我們在下一篇中稍微深入的看看候選執(zhí)行計劃的產(chǎn)生以及估算它們的成本！

轉載于:https://www.cnblogs.com/yanyangtian/archive/2012/03/22/2412723.html

總結

以上是生活随笔為你收集整理的查询优化器内核剖析第一篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。