寫在前面

有人就有江湖，有江湖就有IT系統，有IT系統就有資料庫，有資料庫就有SQL, SQL應用可一字概括:“廣”加之其簡單易學，SQL實現也可一字概括:“樂"。

然而，SQL雖然實現簡單可樂，卻極易引發效能問題，那時廣大SQL使用人員可要“愁”就一個字， 心碎無數次了。

緣何有效能問題?原因也可以用一個字概括:“量”。 當系統資料量、併發訪問量上去後，不良SQL就會拖垮整個系統，我們甚至找不出哪些SQL影響了系統。即便找到也不知如何動手優化。此時的心情也可以用一字概括:“情”。

大家都知道資料是IT系統的核心、重中之重，而SQL是資料互動的必然手段，所以SQL的應用非常廣泛，使用人群數量也非常龐大，因此SQL的重要性不言而喻!

下面我們就深呼吸，用心來感受SQL優化的世界吧。

SQL效能優化手冊

目錄

內容概括

由於筆記涉及到的知識點與內容極多，就不一一展示給大家了，若需要完整版《SQL效能調優手冊》的朋友，可以一鍵三連之後【見下圖】來獲取！！

第1章全域性在胸一用工具對 SQL整體優化

只有站得高，你才看得遠

從前言故事中，大家可以明白一個道理: SQL 優化是一個複雜的工程，首先要講究從整體到區域性。嗯，那我們就從整體開始吧。首先，我們學習關於資料庫整體優化都有哪些效能工具;接著分析這些工具的特點，並結合案例進行探索，最後再進行本章課程的總結和思考。總體學習思路如下圖所示:

都有哪些效能工具

第2章風馳電掣一有 效縮短SQL優化過程

時間都去哪兒了?

第1章似乎讓我們有些熱血澎湃，不過提升效率的重點內容會出現在本章，能否從地下室搬出來，就在此一舉了。

不知大家還記不記得前言故事1中的一個細節，小王發現問題整整花了1個小時，這時間可不短啊。如果系統故障要花整整1小時才能找到，那這1小時時間對客戶來說，是多麼難熬的1小時啊。而且，更可悲的是，這1小時小王並沒有解決問題，故障依舊。

有人問，為啥會花費1小時時間呢?嗯，本章就開始探討這個問題。首先說明調優時間都花在哪兒，接下來分析如何縮短，然後結合案例來鞏固知識，最後大家思考回顧。總體學習思路如下圖所示:

從案例看快速SQL調優

第3章循規蹈矩一如何讀懂SQL執行計劃

很少有DBA能完全讀懂

前兩章給大家介紹了發現問題後的整體解決思路，接下來進入SQL優化的區域性性思路，這一章我們將學習SQL優化的重要知識:執行計劃。

執行計劃是什麼，如何讀懂執行計劃，讀懂執行計劃對我們又有什麼用?面對這些疑問，我們從執行計劃分析概述、讀懂執行計劃的關鍵、從案例中辨別低效SQL、 總結思考這四部分入手開始本章的學習分享，如下圖所示:

讀懂執行計劃的關鍵

第4章運籌帷幄—左右SQL執行計劃妙招

左右執行計劃就是左右人生

經過前面的學習，我們不僅能快速獲取整個資料庫的整體資訊，還能迅速得到SQL的所有詳細資訊。如果能將筆者研發的自動獲取指令碼應用在工作中，在解決問題上則無疑更是如虎添翼。

接下來筆者將教會大家如何真正讀懂執行計劃，這個其實並不容易。循序漸進學完這三個章節後，優化的大方向基本上都清晰了，剩下的就是具體的優化實施。可能會:修改資料庫及主機相關效能引數，根據業務規則修改SQL程式碼，重新收集統計資訊獲取更準確的執行計劃，等等。

• 停!你想過在不改寫SQL和不重新收集統計資訊的情況下，改變SQL的執行計劃嗎?
• 這，可能嗎?
• 當然可以!

不過，0racle 不是很智慧。如果統計資訊正確，應該可以得到正確的執行計劃;如果統計資訊不準確，用收集的方式更合理吧?

你說得太好了!不過假如生產中真的出現了某條SQL由於統計資訊不準確執行非常慢的情況，你立即收集統計資訊這個動作會影響生產吧?如果要等到系統較閒可以收集的時候，這個SQL不是要影響效能很久嗎?

哦，說的是啊。

另外要是萬一出現BUG,某SQL無論如何收集統計資訊都得不到正確的執行計劃，而你明知正確的執行計劃該是怎麼樣的，那你該怎麼辦呢?

自己動手改變執行計劃。

正確!

看來，左右SQL執行計劃還真有用，那我要好好跟你學學。

OK，讓我們開始吧，先看看總體學習思路，如下圖所示:

從案例探索其方法及意義

第5章且慢， 感受體系結構讓SQL飛

前言故事5中，老丁沒有改寫SQL,只是加了一個索引，然後SQL就變快了，這是看起來最省事的方法了。其實我們在接下來的7章裡大部分內容都是教大家如何不改寫SQL完成SQL優化。不過這裡要注意幾點:

1. 你必須深刻理解資料庫的原理;
2. 你能把握業務場景;
3. 接下來的這些章節是教大家如何不改寫SQL進行優化，但也不是全都不用改寫，比如繫結變數、批量提交等還是必須要改造SQL的。

由於筆記已經介紹得比較詳細了，本章會較為簡要地給大家介紹一下體系結構知識，然後描述體系結構和SQL優化的關係。最後通過系列擴充套件的相關優化案例來拓寬我們的視野，從而使我們更深入地瞭解體系結構的原理。最後是思考回顧。本章總體的學習思路如下圖所示:

體系結構知識

第6章且慢，體驗邏輯結構讓SQL飛

你可能沒想過從邏輯結構原理中動手優化

邏輯結構與SQL 優化之間的關係是大部分人容易忽略的，本章我們先從簡單的邏輯結構知識開始介紹，接下來對所有可能和SQL優化有關的邏輯結構的細節做進一步的描述。

隨後就是案例剖析環節，在該環節讓讀者真真切切感知到邏輯結構在影響著工作中的各種場景。最後是思考回顧。本章總體學習思路如下圖所示:

體系細節與SQL優化

第7章且慢，探尋表的設計讓SQL飛

沒想到表設計如此有用

表設計是一個非常重要的技術，這個技術使用得當，將會對應用優化起到巨大的作用。比如某張大表是按所在地區查詢的，如果這表又按地區做分割槽，那SQL的效能馬上就會大幅度提升，比如查福州的時候，就不會去訪問廈門的其他Segment,訪問路徑就會大大縮減。用一句專業點的話來描述就是: SQL 從全掃描轉化成了區域性掃描。當然，類似這樣的例子很多，比如全域性臨時表、索引組織表等。這些是表的型別的設計，除此之外還有欄位的設計，比如欄位的型別、正規化與反正規化等。

如果我們只是站在表的特性上來研究，顯然是不夠的。我們還要緊抓業務，站在業務的層面來思考表設計，這才是最高境界。

接下來我們從表設計知識、表設計與SQL優化、相關案例和總結4個方面展開本章的學習，總體學習思路如下圖所示:

表設計與SQL優化

第8章且慢，學習索引如何讓SQL飛

原來索引的學習如此重要

索引是SOL優化使用頻度最高的優化武器，甚至可以說你對索引有了深刻的理解，你基本上可以優化身邊60%以上的SQL。 如何做到深刻地理解索引呢?最關鍵是知道索引的結構，並且明白這些結構有什麼特點，再思考這些特點和哪些型別的SQL優化有關係。這樣，索引的學習就算畢業了。

本章我們先從索引的知識要點入手，得出索引的結構後我們開始嘗試讓索引的原理和SQL結合起來。後面給大家分析一些經典案例， 讓大家從中得到更多的啟發。最後對索引知識進行一系列延伸。總體學習思路如下圖所示:

索引的SQL優化

第9章且慢，弄清索引之阻礙讓SQL飛

原來索引是一把雙刃劍

任何事物都有它的兩面性，索引也不例外，上一章中我們介紹了索引的各種好處，本章我們主要來闡述索引的壞處。

大家可能沒注意到，上一章中主要都是一些查詢語句，那如果更新語句出現，索引的缺點將很明顯。因為索引本身是有序的，而更新資料的過程中也要更新索引，更新完後還要保持索引的有序性，這就需要付出很大的開銷了，索引不好的一面就從這裡開始顯示出來了。

本章我們先簡要綜述一下索引的不足之處有哪些，接下來詳細闡述，隨後一起和大家探索各種工作中的案例，最後為思考回顧。總體學習思路如下圖所示:

感受美好索引另一面

第10章且慢，其他索引應用讓SQL飛

走進其他索引的精彩世界

前面一章談到了索引的好與壞，不知道大家注意到沒有，這些其實都是一些 普通的Btree索引。其實還有一些比較特殊的索引， 比如點陣圖索引、函式索引、反向鍵索引和全文索引。它們的結構很特殊，應用的場景也比較特殊，不過如果我們能巧妙地將這類索引的特性和業務場景結合起來，在SQL優化上將起到意想不到的效果。本章還是先從其他索引的總體概述開始講述，接著進一步通過各種試驗 瞭解特性，然後進入案例實戰體會環節，最後總結。總體學習思路如下圖所示:

走進其他索引的世界

第11章且慢， 表連線的祕密讓SQL飛

原來表連線原理如此實用

各型別表連線的知識要點

第12章動手，經典等價改寫讓SQL飛

其實等價與否總在一念之間

SQL優化的本質就是減少訪問路徑，前面的章節中我們已經學到了很多減少訪問路徑的思路，比如增加索引從全表掃描轉換成索引範圍掃描，比如把表改造成分割槽表從而從全表掃描轉化成區域性分割槽掃描，這些都屬於不需要改寫SQL就能完成的減少訪問路徑的思路。當然，在很多場景下，我們必須要完成一些等價改寫， 比如case when改造、rownum 分頁改寫，等等。

除了減少訪問路徑外，還要注意避免外因的影響，比如，一些執行計劃不穩定，所在環境的資源不足，等等，這些也是我們需要注意的。

總體思路如下圖:

設法減少訪問路徑

第13章動手， 過程函式優化讓SQL飛

批量與否效果不言而喻

先丟擲一個搬磚的故事來提問:建築工人A將磚頭一塊一塊地從某地運輸到目的地。而建築工人B則用板車裝上磚頭來運輸，請問誰的效率高?答案是:當磚頭特別多的時候，肯定是後者效率高。

搬磚其實就反映了PL/SQL 程式碼的優化思路。在PL/SQL 中一般都是基於遊標迴圈的各種寫法，就是建築工人A在幹活。而接下來我要告訴大家一個集合的概念，如果能用集合的寫法來完成PL/SQL的優化改造，優化效果會好得多!這就是建築工人B在幹活。

集合的優化是本章的重點內容。同時還將介紹定義型別的優化、動態SOL的優化和一些其他相關擴充套件案例。本章總體學習思路如下圖所示:

PL/SQL優化其他相關擴充套件

第14章動手，高階寫法應用讓SQL飛

高階與否答案自在心中

同學們，現在我們開始學習高階SQL讓效能提升的方法...

停!天哪，難道之前我們學的都是低階SQL嗎，退學費!

冷靜，其實這裡說的高階SQL,只是一種說法，大概就是一些看起來有些不尋常的特殊SQL，比如insert all 語句、with子句、merge 等。這些SQL有一個共同的特點，就是它們都在內部被優化過了，可以通過比較簡單、單步驟的語法來實現複雜和多步驟的功能，同時在效能上還能有不少提升。

本章總體學習思路如下圖所示:

高階SQL介紹與案例

第15章動手， 分析函式讓SQL飛

分析函式是世上最優雅的寫法

分析函式是Oracle 8i引入的一個全新的概念，其為我們分析資料提供了一種簡單高效的處理方式。在分析函數出現之前，我們必須使用自聯查詢、子查詢或者內聯檢視，甚至是複雜的儲存過程實現的語句，現在只要一條 簡單的SQL語句即可實現，而且在執行效率方面也有相當大的提高。

Oracle分析函式實現了一些我們需要編碼才能實現的統計功能，這對於簡化我們的開發工作有很大的幫助，特別是在開發BI報表時有意想不到的效果;同時我們也可以利用分析函式來實現一些特殊的需求。

分析函式詳解與案例

第16章動手，把握需求改寫讓SQL飛

入木三分你需要讀懂本質

來，先看一段對話吧:

老師，幫我優化一下這個SQL吧。

好的。

小王，你是不是給錯SQL了，這SQL也就1s出來了，邏輯讀也不過20。

老師，就這語句，這語句每小時要執行1千萬次啊!

哦，這樣，為啥要執行這麼多次，你去了解一下。那我再看看，好嗎?

好的。

我們來看看這段短短的對話，其實內在還是有很多玄機的。首先就是老師為啥會說這個語句給錯了，因為他看到語句執行得很快，邏輯讀也很少，覺得SQL優化空間不大，使用者的感知應該也不會太明顯。其次，當他聽說語句執行次數達到每小時上千萬次時，又要再去看看，因為累積起來，對系統總體的效能影響是很大的。比如邏輯讀從20降到10，那1千萬次意味著每小時系統的邏輯讀減少了1億個，這是多驚人的數字啊。最後老師同時還讓小王去了解為什麼要執行這麼多次，這意味著老師想從業務層面入手，瞭解這1千萬次執行的必要性，看看能否直接將執行次數降下來。

這段對話是非常經典的對話，折射出"了 解需求，理清業務關係”是非常重要的!這個語句如果能根據業務或者特定的語法進行等價改寫，或許就能再提升。而如果能根據對業務的準確理解，巧妙地降低了執行的次數，這個優化工作就已經可以結束了。

總結起來就是，你要確保具備等價改造SQL的意識和本領，然後再大膽結合業務，把握真正的需求，完成優化改造。

總體學習思路如下圖所示:

開發設計應用中的需求

第17章總結與延伸: 從勿信訛傳到洞若觀火

整本筆記都寫完了，從優化方法論到具體的優化各種知識。不過，還有一些其他的認識需要在全書的最後做一個補充，那就是:如何讓自己有一個清醒冷靜的頭腦。這是非常有必要的，因為在現在的網際網路時代，到處都充斥著虛假錯誤的資訊，不明真相的人很容易瞎轉或者盲從，不判斷真偽，到最後甚至給自己造成了很大的損失。SQL 優化也不例外，網路上很多所謂的優化寶典等描述的建議都是錯誤的或者是過時的，你信嗎?如果不信， 請看隨後的關於SQL優化的各種謠傳。都是有指令碼有真相哦。

想弄清楚這所有的疑問，一起跟我往下看，先從SQL優化的訛傳開始。

談SQL編寫順序之流言蜚語

由於筆記涉及到的知識點與內容極多，就不一一展示給大家了，若需要完整版《SQL效能調優手冊》的朋友，可以一鍵三連之後【見下圖】來獲取！！

名家力薦

總結

這份筆記安排的章節遠遠不夠覆蓋所有的SQL優化知識，具體的SQL優化內容也無法做到詳細盡地展開，一方面限於篇幅，另一方面也限於筆者的知識水平。不過，我認為詳盡的優化百科大全實際對讀者來說並不是最重要的。我將訛傳辨識與思維探索作為全書的最後一個章節，就是想告訴大家:質疑探索比學習更重要!

然後，請你看看全書目錄，難道你不覺得，SQL 優化不只是一門技術，更是一門藝術!將基於實戰的優化方法論融合在美麗的思維導圖裡，我們看到的，是優化之美!