查詢優(yōu)化器內(nèi)核剖析第四篇：從一個實例看執(zhí)行計劃 系列文章索引：???????

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

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

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

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

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

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

?

??? 這幾天也收到了一些朋友的來信說：為什么你花這么多的時間將這些東西，直接告訴我性能優(yōu)化的方法就行了。這個問題，其實早就說過了：學習查詢優(yōu)化器不是我們的目的，而是通過它，我們掌握SQL Server是如何處理我們的SQL的，掌握執(zhí)行計劃，掌握為什么產(chǎn)生I/O問題，為什么CPU使用老高，為什么你的索引加了不起作用… ??? 如果，我告訴你，你去加個索引，換SAN存儲，這樣意義不大！數(shù)據(jù)庫優(yōu)化就是這樣的：沒有所謂的“絕對手段，一下子把性能搞上去，一切都是看情況而定”，都是通過不斷的分析，抽絲剝解。不帶頭腦的優(yōu)化，能好到那里去？ ?????在前幾篇文章中，我們已經(jīng)談了一些查詢優(yōu)化器的相關(guān)的基礎(chǔ)介紹，也大致的了解了它到底是干什么的。查詢優(yōu)化器的結(jié)果就是產(chǎn)生執(zhí)行計劃，執(zhí)行計劃就是一個樹，這個樹由很多的物理操作組成，而這些物理操作就定義了如何去存儲設(shè)備中去獲取數(shù)據(jù)。 ???? 我們可以以很多的不同的方式，例如圖形化，文本，XML的形式來查看一個給定查詢的實際的執(zhí)行計劃和估計的執(zhí)行計劃。這些不同格式的執(zhí)行計劃的區(qū)別主要在于包含的信息的詳細程度不同。 ?????? ??? 當需要查看一個查詢的實際的執(zhí)行計劃的時候，這個查詢比較要執(zhí)行。然而，如果查看估計的執(zhí)行計劃，此時整個查詢是不需要實際執(zhí)行的。如果查詢是個需要消耗很長時間，很多資源的查詢，我們在分析問題的時候，會先查看這個查詢估計的執(zhí)行計劃，并且這樣做也不會對使用數(shù)據(jù)庫的其他用戶產(chǎn)生影響。 ?????查看實際執(zhí)行計劃和估計的執(zhí)行計劃方式有很多，最簡單的方式就是在SQL Server管理界面點擊如下按鈕： ?????查看估計的執(zhí)行計劃： 查看實際的執(zhí)行計劃?: ??? 下面，我們就來通過一個簡單的示例講述執(zhí)行計劃，這里采用示例數(shù)據(jù)庫：AdventureWorks。 ?????我們在SQL Server中輸入以下查詢： ??? 然后，點擊“Include Actual Execution Plan”按鈕，然后執(zhí)行SQL語句，看到如下顯示： ??? 在圖中，我們可以看到一些物理操作符號以圖標顯示，例如Index Scan，Hash Aggregate。第一個圖標稱為結(jié)果操作符，它返回了查詢的結(jié)果。 ????? ??? 每一個物理的操作符，其實就是存儲引擎中實現(xiàn)的一些基本的操作或者方法。例如，一個邏輯的join（就是我們在SQL寫的inner join之類的），可以再執(zhí)行計劃中以不同的物理join操作實現(xiàn)（Nested Loops Join, Merge Join, Hash Join）。當然，這里沒有所謂的“那種物理操作好，哪種不好”，得看具體情況。 ?????????? ??? 每個物理操作執(zhí)行的時候，就會去獲取一些數(shù)據(jù)，然后將數(shù)據(jù)傳遞給它下一個物理操作，知道全部的操作完成，返回結(jié)果。在查看執(zhí)行計劃的時候，需要“從右向左，從下到上”進行。 在執(zhí)行計劃中，每個物理操作都有一些“箭頭”相連，這些箭頭就表明了執(zhí)行的先后順序，并且箭頭的粗細也放映了傳遞數(shù)據(jù)的多少，越粗就表明數(shù)據(jù)越多。?????????? ?? ??? ?我們可以通過把鼠標放在這些箭頭上面，查看更多的信息。如下： ?? 通過查看提示信息，我們可以知道：Index Scan這個操作讀取了19614條數(shù)據(jù)，這些數(shù)據(jù)之后被傳遞給了Hash? Aggregate操作。Hash? Aggregate執(zhí)行之后，就將這些數(shù)據(jù)通過City字段做了一個distinct的處理，將575條數(shù)據(jù)給了下一個操作： ??? 對于執(zhí)行計劃中出現(xiàn)的一些物理操作，一般基本會通過三個方法來實現(xiàn)它們的功能（這里要把操作和方法的概念搞清楚，可能在很多的編程語言中，一個操作就是一個方法，或者說操作就是方法，這里的操作和方法和那些不同，一個操作是有幾個方法來實現(xiàn)和完成的,為了便于理解，大家這里就把每一個操作理解為一個類吧）： ?????????????? Open()方法：這個方法初始化一個物理操作 ?????????????? GetRow()方法：這個方法每次都從它的上一個操作中獲取一行數(shù)據(jù) ?????????????? Close()方法：執(zhí)行完畢，做一些相關(guān)的清理等工作 ?????????????? ??? 因為GetRow()方法每次只能從上一個操作中獲取一個數(shù)據(jù)，那么如果上一個操作傳遞了很多的數(shù)據(jù)，那么這個物理操作就要多次調(diào)用上一個操作的GetRow()方。在上面的例子中，Hash? Aggregate操作只調(diào)用一次Index Scan的Open()方法，然后調(diào)用19615次Index Scan的GetRow()方法，最后調(diào)用一次Index Scan的Close()方法。 ??? 其實我們還可以通過這個圖形化的執(zhí)行計劃得到更多的信息！為了使得大家更好地消化今天的知識，余下的內(nèi)容，下次接著講述。

轉(zhuǎn)載于:https://blog.51cto.com/yanyangtian/814688

總結(jié)

以上是生活随笔為你收集整理的查询优化器内核剖析第四篇：从一个实例看执行计划的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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