你真的瞭解「SQL」嗎?《SQL優化最佳實踐》做者帶你從新瞭解SQL

1、SQL :一種熟悉又陌生的編程語言

這裏有幾個關鍵詞;「熟悉」、「陌生」、「編程語言」。sql

說它「熟悉」,是由於它是DBA和廣大開發人員,操做數據庫的主要手段,幾乎天天都在使用。說它「陌生」,是不少人只是簡單的使用它,至於它是怎麼工做的?如何才能讓它更高效的工做?卻歷來沒有考慮過。數據庫

這裏把SQL歸結爲一種「編程語言」,可能跟不少人對它的認知不一樣。讓咱們看看它的簡單定義(如下內容摘自百度百科)編程

結構化查詢語言(Structured Query Language),簡稱SQL,是一種特殊目的的編程語言,是一種數據庫查詢和程序設計語言,用於存取數據以及查詢、更新和管理關係數據庫系統。結構化查詢語言是高級的非過程化編程語言,容許用戶在高層數據結構上工做。它不要求用戶指定對數據的存放方法,也不須要用戶瞭解具體的數據存放方式,因此具備徹底不一樣底層結構的不一樣數據庫系統, 可使用相同的結構化查詢語言做爲數據輸入與管理的接口。結構化查詢語言語句能夠嵌套,這使它具備極大的靈活性和強大的功能。

總結一句話,SQL是一種非過程化的的編程語言,可經過它去訪問關係型數據庫系統。緩存

2、你真的瞭解「SQL」嗎?

下面我會經過一個小例子,看看你們是否真正瞭解SQL。數據結構

這是一個很簡單的示例,是關於SQL語句執行順序的。這裏將一個普通的SELECT語句,拆分爲三個子句。那麼在實際的執行過程當中,是按照什麼順序處理的呢?這裏有A-F六個選項,你們能夠思考選擇一下…架構

最終的答案是D,即按照先執行FROM子句,而後WHERE子句,最後是SELECT部分。併發

針對上面的示例,讓咱們真實構造一個場景,經過查看執行計劃看看是否按照咱們選擇的順序執行的。關於執行計劃的判讀,我後面會專門談到。這裏我先解釋一下整個執行過程。oracle

  • 第一步,是按照全表掃描的方式訪問了對象表(EMP)。對應於語句中的FROM部分。
  • 第二步,是對提取出的結果集進行了過濾(filter部分),即將知足條件的記錄篩選出來。對應於語句中的WHERE部分。
  • 第三步,是對知足條件的記錄進行字段投射,即將須要顯示的字段提取出來。對應於語句中的SELECT部分。

這是一個詳細的SQL各部分執行順序的說明。app

經過對執行順序的理解,能夠爲咱們將來的優化工做帶來很大幫助。一個很淺顯的認識就是,優化動做越靠前越好。運維

3、SQL如今是否仍然重要?

這裏引入了一個新的問題,在現有階段SQL語言是否還重要?

之因此引入這一話題,是由於隨着NOSQL、NEWSQL、BIGDATA等技術逐步成熟推廣,「SQL語言在現階段已經變得不那麼重要」成爲一些人的觀點。那實際狀況又是如何呢?

讓咱們先來看一張經典的圖。圖中描述了傳統SMP架構的關係型數據庫、MPP架構的NEWSQL、MPP架構的NoSQL不一樣方案的適用場景對比。

從上面的「數據價值密度、實時性」來看,傳統關係型數據庫適合於價值密度更高、實時性要求更高的場景(這也就不難理解相似帳戶、金額類信息都是保存在傳統關係型數據庫中);MPP架構的NewSQL次之,MPP架構的NoSQL更適合於低價值、實時性要求不高的場景。

從下面的「數據規模」來看,傳統關係型數據庫適合保存的大小限制在TB級別,然後二者可在更大尺度上(PB、EB)級保存數據。

從下面的「典型場景」來看,傳統關係型數據庫適合於OLTP在線交易系統;MPP架構的NewSQL適合於OLAP在線分析系統;而NoSQL的使用場景較多(利於KV型需求、數據挖掘等都可以考慮)。

最後從「數據特徵」來看,前二者適合於保存結構化數據,後者更適合於半結構化、乃至非結構化數據的保存。

概括一下,不一樣技術有其各自特色,不存在誰代替誰的問題。傳統關係型數據庫有其自身鮮明特色,在某些場合依然是不二選擇。而做爲其主要交互語言,SQL必然長期存在發展下去。

咱們再來對比一下傳統數據庫與大數據技術。從數據量、增加型、多樣化、價值等維度對比兩種技術,各自有其適用場景。

對於大數據領域而言,各類技術層出不窮。但對於廣大使用者來講,每每會存在必定的使用門檻,所以如今的一種趨勢就是在大數據領域也引入「類SQL」,以相似SQL的方式訪問數據。這對於廣大使用者來講,無疑大大下降了使用門檻。

解答一些疑問:

NoSQL、NewSQL已經超越了傳統數據庫,SQL沒有了用武之地!

各類技術有着各自適合的不一樣場景,不能一律而論。SQL語言做爲關係型數據庫的主要訪問方式,依然有其用武之地。

之後都是雲時代了,誰還用關係型數據庫!

對於價值密度高,嚴格一致性的場景,仍然適合採用關係型數據庫做爲解決方案。

我編程都是用OR Mapping工具,從不須要寫SQL!

的確,引入OR Mapping工具大大提升了生產效率,可是它的反作用也很明顯,那就是對語句的運行效率失去了控制。不少低效的語句,每每是經過工具直接生成的。這也是爲何有的Mapping工具還提供了原始的SQL接口,用來保證關鍵語句的執行效率。

大數據時代,咱們都用Hadoop、Spark了,不用寫SQL啦!

不管是使用Hadoop、Spark都是能夠經過編寫程序完成數據分析的,但其生產效率每每很低。這也是爲何產生了Hive 、Spark SQL等「類SQL」的解決方案來提升生產效率。

數據庫處理能力很強,不用太在乎SQL性能!

的確,隨着多核CPU、大內存、閃存等硬件技術的發展,數據庫的處理能力較之前有了很大的加強。可是SQL的性能依然很重要。後面咱們能夠看到,一個簡單SQL語句就能夠輕易地搞垮一個數據庫。

SQL優化,找DBA就好了,我就不用學了!

SQL優化是DBA的職責範疇,但對於開發人員來說,更應該對本身的代碼負責。若是能在開發階段就注重SQL質量,會避免不少低級問題。

我只是個運維DBA,SQL優化我不行!

DBA的發展可分爲「運維DBA->開發DBA->數據架構師…」。若是隻能完成數據庫的運維類工做,無疑是技能的欠缺,也是對各人將來發展不利。何況,隨着Paas雲的逐步推廣,對於數據庫的運維需求愈來愈少,對於優化、設計、架構的要求愈來愈多。所以,SQL優化是每一個DBA必須掌握的技能。

如今優化有工具了,很簡單的!

的確如今有些工具能夠爲咱們減小些優化分析工做,會自動給出一些優化建議。可是,做爲DBA來說,不只要知其然,還要知其因此然。何況,數據庫優化器自己就是一個很是複雜的組件,很難作到徹底無誤的優化,這就須要人工的介入,分析。

優化不就是加索引嘛,這有啥!

的確,加索引是一個很是經常使用的優化手段,但其不是惟一的。且不少狀況下,加了索引可能致使性能更差。後面,會有一個案例說明。

4、SQL仍然很重要!

咱們經過一個示例,說明一下理解SQL運行原理仍然很重要。

這是我在生產環境碰到的一個真實案例。Oracle數據庫環境,兩個表作關聯。執行計劃觸目驚心,優化器評估返回的數據量爲3505T條記錄,計劃返回量127P字節,總成本9890G,返回時間999:59:59。

從執行計劃中可見,兩表關聯使用了笛卡爾積的關聯方式。咱們知道笛卡爾鏈接是指在兩錶鏈接沒有任何鏈接條件的狀況。通常狀況下應儘可能避免笛卡爾積,除非某些特殊場合。不然再強大的數據庫,也沒法處理。這是一個典型的多表關聯缺少鏈接條件,致使笛卡爾積,引起性能問題的案例。

從案例自己來說,並無什麼特別之處,不過是開發人員疏忽,致使了一條質量不好的SQL。但從更深層次來說,這個案例能夠給咱們帶來以下啓示:

  • 開發人員的一個疏忽,形成了嚴重的後果,原來數據庫竟是如此的脆弱。須要對數據庫保持一種"敬畏"之心。
  • 電腦不是人腦,它不知道你的需求是什麼,只能用寫好的邏輯進行處理。
  • 不要去責怪開發人員,誰都會犯錯誤,關鍵是如何從制度上保證再也不發生相似的問題。

5、SQL優化法則

下面咱們來看看常見的優化法則。這裏所說的優化法則,實際上是指能夠從那些角度去考慮SQL優化的問題。能夠有不少種方式去看待它。下面列舉一二。

這裏來自阿里-葉正盛的一篇博客裏的一張圖,相信不少人都看過。這裏提出了經典的漏斗優化法則,高度是指咱們投入的資源,寬度是指可能實現的收益。從圖中可見,「減小數據訪問」是投入資源最少,而收益較多的方式;「增長硬件資源」是相對投入資源最多,而收益較少的一種方式。受時間所限,這裏不展開說明了。

這是我總結的一個優化法則,簡稱爲「DoDo」法則。

第一條,「Do Less or not do!」翻譯過來,就是儘可能讓數據庫少作工做、甚至不作工做。

怎麼樣來理解少作工做呢?好比建立索引每每能夠提升訪問效率,其原理就是將原來的表掃描轉換爲索引掃描,經過一個有序的結構,只須要少許的IO訪問就能夠獲得相應的數據,所以效率才比較高。這就能夠概括爲少作工做。

怎麼樣來理解不作工做呢?好比在系統設計中常見的緩存設計,不少是將原來須要訪問數據庫的狀況,改成訪問緩存便可。這樣既提升了訪問效率,又減小了數據庫的壓力。從數據庫角度來講,這就是典型的不作工做。

第二條,「If must do,do it fast!」翻譯過來,若是數據庫必須作這件事件,那麼請儘快作完它。

怎麼樣來理解這句話呢?好比數據庫裏常見的並行操做,就是經過引入多進程來加速原來的執行過程。加速處理過程,能夠少佔用相關資源,提升系統總體吞吐量。

6、SQL 執行過程

SQL的執行過程比較複雜,不一樣數據庫有必定差別。下面介紹以兩種主流的數據庫(Oracle、MySQL)介紹一下。

  • 用戶提交了一條SQL語句
  • 數據庫按照SQL語句的字面值計算出一個HASH值
  • 根據HASH值,判斷一下在數據庫緩衝區中是否存在此SQL的執行計劃。
  • 若是不存在,則須要生成一個執行計劃(硬解析過程),而後將結果存入緩衝區。
  • 若是存在的話,判斷是否爲相同SQL(一樣HASH值的語句,可能字符不相同;即便徹底相同,也可能表明不一樣的語句。這塊不展開說了)
  • 確認是同一條SQL語句,則從緩衝區中取出執行計劃。
  • 將執行計劃,交給執行器執行。
  • 結果返回給客戶端。

  • 客戶提交一條語句
  • 如今查詢緩存查看是否存在對應的緩存數據,若有則直接返回(通常有的可能性極小,所以通常建議關閉查詢緩存)。
  • 交給解析器處理,解析器會將提交的語句生成一個解析樹。
  • 預處理器會處理解析樹,造成新的解析樹。這一階段存在一些SQL改寫的過程。
  • 改寫後的解析樹提交給查詢優化器。查詢優化器生成執行計劃。
  • 執行計劃交由執行引擎調用存儲引擎接口,完成執行過程。這裏要注意,MySQL的Server層和Engine層是分離的。
  • 最終的結果有執行引擎返回給客戶端,若是開啓查詢緩存的話,則會緩存。

7、SQL優化器

在上面的執行過程描述中,屢次提升了優化器。它也是數據庫中最核心的組件。下面咱們來介紹一下優化器。

上面是我對優化器的一些認識。優化器是數據庫的精華所在,值得DBA去認真研究。可是遺憾的是,數據庫對這方面的開放程度並不夠。(相對來講,Oracle仍是作的不錯的)

這裏咱們看到的MySQL的優化器的工做過程,大體經歷了以下處理:

  • 詞法分析、語法分析、語義檢查
  • 預處理階段(查詢改寫等)
  • 查詢優化階段(可詳細劃分爲邏輯優化、物理優化兩部分)
  • 查詢優化器優化依據,來自於代價估算器估算結果(它會調用統計信息做爲計算依據)
  • 交由執行器執行

此圖是DBAplus社羣MySQL原創專家李海翔對比不一樣數據庫優化器技術所總結的。從這裏能夠看出:

  • 不一樣數據庫的實現層次不一樣,有些支持、有些不支持
  • 即便支持,其實現原理也差別很大
  • 這只是列出了一小部分優化技術
  • 以上對比,也能夠解釋不一樣數據庫對一樣語句的行爲不一樣。下面會有一個示例說明

8、SQL 執行計劃

看懂執行計劃是DBA優化的前提之一,它爲咱們開啓一扇通往數據庫內部的窗口。可是很遺憾,從沒有一本書叫作「如何看懂執行計劃」,這裏的狀況很是複雜,不少是須要DBA常年積累而成。

這是Oracle執行計劃簡單的示例,說明了執行計劃的大體內容。

9、案例分享

前面講了不少理論內容,下面經過幾個案例說明一下。方便你們對前面內容的理解。

案例1:數據庫對比

第一個例子,是一個優化器行爲的對比案例。示例對比了三種數據庫(四種版本)對於一樣語句的行爲。經過這個例子,你們能夠了解,不一樣數據庫(乃至不一樣版本)優化器的行爲不一樣。對於數據庫選型、數據庫升級等工做,要作到充分的評估測試,也正是出於此目的。

簡單構造了兩張測試表,主要注意的是前一個字段是包含空值的。

第一種狀況,是對於IN子查詢的處理。對於Oracle來講,10g、11g行爲相同,這裏就列了一個。

對於這樣的一個例子,不一樣數據庫已經表現出不一樣的差別。Oracle和PG的行爲相似,MySQL因爲不支持哈希鏈接,所以採用了其餘處理方式。具體的技術細節,這裏不展開說明了。

第二種狀況,是對於NOT IN子查詢的處理。這種狀況下,Oracle的不一樣版本、PG和MySQL表現出不一樣的行爲。從上面例子能夠看出,11g的優化器在處理此種狀況是更加智能一些。

案例2:解決「ERP匯單慢」問題

這裏我構造了相似的結構,模擬了上線的狀況。

示例是一個關聯子查詢,其核心部分是轉化爲一個表關聯,並使用了嵌套循環的一個變體-Filter實現關聯方式。顯然,若是外層表過大或內層探查效率太低,其執行效率可想而知。一般來講,兩表關聯,嵌套循環是最後的一種選擇,若是能使用其餘方式(例如HASH JOIN、SORT MERGE)可能會帶來更好的效果。

這裏優化器沒有選擇更優的計劃,是優化器的Bug?仍是功能所限?可經過人工手段干預,看看是否能達到意向不到的效果。

引入了一個Hint-unnest,主動實現子查詢的解嵌套。將子查詢部分提早,讓優化器有了更多的選擇。從執行計劃來看,優化器生成了一個內聯視圖,而後跟外部表實現了一個哈希鏈接,總體效率大大提升。

這個示例說明,優化器的功能仍是有所侷限。在某些場合,能夠人工干預語句的執行,提高總體執行效率。

案例3:處理「ERP清理數據」問題

下面這個示例,是由於結構設計不良致使的問題。

在平常的優化中,咱們每每遵循着「語句級、對象級、架構級、業務級」的順序考慮優化策略。但在項目需求、設計階段,是按照反向的順序進行。後者的影響力要遠遠大於前者。一個糟糕的對象結構設計,可能會帶來一系列SQL的問題。示例中,就是這樣的一個問題。

這是某公司後臺的ERP系統,系統已經上線運行了10多年。隨着時間的推移,累積的數據量愈來愈大。公司計劃針對部分大表進行數據清理。在DBA對某個大表進行清理中,出現了問題。這個表自己有數百G,按照指定的清理規則只須要根據主鍵字段範圍(>=)選擇出必定比例(不超過10%)的數據進行清理便可。但在實際使用中發現,該SQL的是全表掃描,執行時間大大超出預期時間。DBA嘗試使用強制指定索引方式清理數據,依然無效。

這套ERP系統歷史好久遠,相關信息已經找不到了。只能從純數據庫的角度進行分析,這是一個普通表(非分區表)按照主鍵字段的範圍查詢一批記錄進行清理。按照正常理解,執行索引範圍掃描應該是效率較高的一種處理方式,但實際狀況確實全表掃描。進一步分析發現,該表的主鍵是沒有業務含義的,僅僅是自增加的數據,其來源是一個序列。但奇怪的是,這個主鍵字段的類型是變長文本類型,而不是一般的數字類型。如今已經無從考證,當初定義該字段類型的依據,但實驗代表正是這個字段的類型「異常」,致使了錯誤的執行路徑。

下面構造了一個測試環境。

能夠很好的復現案例的問題。選擇少範圍數據,文本方式依然走的全表掃描,數字方式走的索引掃描。效率高低,顯而易見。

你們頭腦中能夠構想出一棵索引樹結構,對於字符串來講,這個有序的結構該如何存放?是與你預期同樣的嗎?

知道了問題所在,該如何處理呢?修改結構無疑成本過高,不具有可操做性。這裏所採起的策略是「局部有序」。利用修改語句中條件的範圍,由開放區間變爲封閉區間,影響基數的選擇。(關於這部分,你們有興趣可多看看《基於成本的Oracle優化》一書)

如仍然不起做用,可考慮進一步細化分段或乾脆採用「逐條提取+批綁定」的方式解決。

一個小小的數據類型設置不當,會爲咱們後面的工做帶來的多大的麻煩。

案例4: 「抽絲剝繭」找出問題所在

這裏會描述一次完整的優化過程,看看DBA是如何「抽絲剝繭」,發現問題本質的。

這個案例自己不是爲了說明某種技術,而是展示了DBA在分析處理問題時的一種處理方式。其採用的方法每每是根據本身掌握的知識,分析判斷某種可能性,而後再驗證確認是不是這個緣由。在不斷的拋出疑問,不斷的驗證糾錯中,逐步接近問題的本質。

也想經過這個示例,告知廣大開發人員,DBA優化語句的不容易。

這是某數據倉庫系統,有一個做業在某天出現較大延遲。爲了避免影響明天的業務系統,必須在今天解決這個問題。經和開發人員的溝通,該業務的SQL語句沒有修改,相關的數據結構也沒有變動相相似的其餘業務(SQL語句類似的)也都正常運行,數據庫系統自己也沒有異常。

修改後執行計劃,跟其餘相似SQL相同了。整個計劃可概述爲」HASH JOIN」 + 「FULL TABLE SCAN」。經測試,速度略有提高,可是整個運行時間仍然超過2個小時。

開始了第一次嘗試,開始想到的方法很簡單,既然相似的SQL執行效率沒問題,而這個SQL因爲其餘SQL執行計劃誤差較大,我能夠手工採起固化執行計劃的方法。這裏使用了抽取OUTLINE的方式。經測試,對速度提高不大,不知問題主因。

第二次嘗試,從等待事件角度入手。首先考慮的是和緩存有關的問題。

不要盲目相信別人的話,優化以前先按照故有流程檢驗一遍,作到心中有數。對於此例來講,能夠大大加快問題的解決。

Q&A

Q1:ANSI 的SQL標準,會一直推出新版本嗎? 後續版本是否會加入新的語法和特性呢?

A1:這個問題沒有仔細考慮過,ANSI-SQL的標準一直在變化,不一樣的數據庫根據自身狀況實現了它的子集。從我我的角度來看,將來ANSI-SQL可能會對大數據、數據挖掘方向有所考慮,加入部分新語法或特性。畢竟SQL接口做爲人們最爲熟悉的數據訪問接口,將來在大數據等方向大有可爲。

Q2:優化SQL最終的目的是否是改變SQL執行計劃?

A2:第一目的,是理解現有優化器選擇的行爲,並考慮是不是最佳選擇。第二目的,是在優化器功能有所侷限的狀況下,經過人工介入的方式,讓數據庫以更優的方式執行SQL。畢竟人要比電腦更理解數據。

Q3:能不能介紹一下開發中,數據類型的選擇對數據庫的影響?

A3:數據類型在優化層面,主要可從如下角度考慮:

選擇「合適」的類型存儲數據。注意,這裏使用的詞是「合適」,要確保精度、夠用、不浪費的原則。

數據類型在數據庫自身存儲、計算上的特性,不一樣類型的效率是不一樣的。

類型間要作到兼容,保證關聯字段的類型一致性。

Q4:能不能介紹下oracle數據遷移的經常使用方式和利弊?

A4:這個有不少,取決於遷移的需求,好比經常使用的:

1.備份、恢復;2.邏輯導入、導出(含傳輸表空間等);3.DATAGUARD;4.LOG SYNC(例如OGG等);5.程序同步……利弊,主要取決於成本、代價了,每種方案都有自身的適用場景。

Q5:請問必須全表掃描的語句有什麼優化思路?

A5:必須用全表掃描的狀況,就適用於分享中的「DoDo」原則第二條,儘可能讓其更快的完成。可考慮的策略有:

  • DIRECT PATH READ
  • 加大MULTI BLOCK READ COUNT
  • 啓用PARALLEL
  • 更好的IO

Q6:對於group by語句如何優化?

A6:對於分組來講,Oracle 11g之後的版本提供了HASH GROUP BY的實現。HASH是個重內存消耗操做,可從內存使用角度基於優化考慮。

Q7:訪問路徑是會緩存起來的,怎麼判斷回收沒用的緩存中的訪問路徑呢?

A7:通常不須要考慮回收問題,若是非要作可從內存信息中瞭解此執行計劃是否最近被使用,使用DBMS包清除便可。

Q8:oracle發如今雲機上安裝以後,在併發性方面不行,這是爲何?

A8:不一樣雲的實現策略不一樣。併發性方面,可考慮從vCPU使用、IO等方面着手。這方面經驗很少,抱歉!

Q9:全表掃描想辦法修改成索引全表掃描是否合適?使用with子句來優化sql,這個手段如何?

A9:將全表掃描修改成索引全掃描,根本原則是可以縮小訪問量,即讓數據庫幹更少的活。

WITH子句,定義查詢塊,一個目的是減小屢次引用,但也有可能出現不容許執行查詢語句變形的狀況,要具體分狀況分析。

做者:韓鋒

DBAplus社羣分享

內容來源:宜信技術學院

相關文章
相關標籤/搜索