SQL性能第3篇：多表訪問方法

平臺開發 360雲計算

女主宣言

在SQL性能概述的第一部分中，咱們研究了關係優化；第二部分介紹了查詢分析，並介紹了單表訪問路徑公式。在今天的文章中，咱們將繼續討論能夠用於組合來自多個表的數據的各類方法。但願對你們在SQL性能優化方面有所幫助。

PS：豐富的一線技術、多元化的表現形式，盡在「360雲計算」，點關注哦！

• SQL性能第1篇：關係優化
  

• SQL性能第2篇：查詢分析和訪問路徑制定
  

在SQL性能概述的第一部分中，咱們研究了關係優化；第二部分介紹了查詢分析，並介紹了單表訪問路徑公式。在今天的文章中，咱們將繼續討論能夠用於組合來自多個表的數據的各類方法。

1

鏈接查詢

當訪問多個表時，優化器必須肯定如何以最有效的方式組合這些表。在肯定鏈接的訪問路徑時，優化器必須肯定錶鏈接的順序，計算每一個訪問路徑的整體成本估計，併爲特定查詢選擇鏈接方法。DBMS 可使用幾種不一樣的方法來鏈接表。

無論 join 方法如何，DBMS都必須作出幾個決策並執行某些操做。第一個決策是首先選擇要處理的表——這個表稱爲外部表。接下來，在外部表上執行一系列操做，爲鏈接作好準備。而後將該表中的行與第二個表（稱爲內部表）中的行組合。在鏈接發生以前、鏈接發生時或二者同時發生時，還會對內部表執行一系列操做。

儘管全部鏈接在功能上都很類似，可是每一個鏈接方法在幕後的工做方式都不一樣。讓咱們研究兩種常見的鏈接方法：嵌套循環鏈接和合並掃描鏈接。

內循環鏈接經過比較外部表和內部表的符合條件的行來工做。在外部表中標識符合條件的行，而後掃描內部表以查找匹配項。限定行是表中列的謂詞匹配的行。當內部表掃描完成時，將標識外部表中的另外一個符合條件的行。再次掃描內部表以查找匹配項，以此類推。內部表的重複掃描一般使用索引來完成，以免沒必要要的I/O開銷。內部表的大小越小，嵌套循環鏈接執行得越好，由於對於外部表的每一個符合條件的行，須要掃描的行越少。

第二種鏈接方法是合併掃描鏈接。在合併掃描鏈接中，要鏈接的表是按鍵排序的。這種排序能夠經過排序或經過索引訪問來完成。在確保外部表和內部表的順序正確以後，將按順序讀取每一個表，並匹配鏈接列。在合併掃描鏈接期間，任何表中的行都不會被讀取超過一次。當一個（或兩個）表上沒有合適的索引時，合併掃描鏈接是有益的。

根據DBMS的不一樣，也可使用其餘鏈接方法。例如，支持數據倉庫和分析查詢的星型鏈接在許多 DBMS 中很常見。還能夠支持其餘混合方法和使用散列的方法。

2

鏈接順序和表選擇

優化器檢查查詢中的每一個鏈接，並分析適當的統計信息，以肯定訪問表以完成鏈接的最佳順序。爲了找到最優的鏈接訪問路徑，優化器使用內置的算法，其中包含關於鏈接和數據量的知識。它將此智能與鏈接謂詞、數據庫統計信息和可用索引相匹配，以估計哪一種順序更有效。通常狀況下，優化器將部署一個算法，該算法將最小化必須訪問內部表的次數，以得到符合條件的外部錶行。

優化器瞭解每種方法的優缺點，以及該方法的使用如何影響性能。根據系統編目中的當前統計信息，優化器選擇最適合內部表和外部表的表。如下是優化器必須考慮的一些問題的高級總結：

• 表越小，就越有可能被選爲外部表。這有助於減小必須從新訪問內部表的次數。

• 若是可以應用選擇謂詞，則更有可能選擇表做爲外部表，由於只有知足應用於外部表的謂詞的行才能訪問內部表。

• 若是能夠對其中一個表執行索引查找，那麼該表是用做內部表的一個很好的候選表。若是一個表沒有索引，那麼它就不適合用於內部表，由於必須爲外部表的每一行掃描整個內部表（對於嵌套循環鏈接）。

• 重複最少的表可能傾向於被選擇爲聯接中的外部表。

固然，這些都不是硬性規定。最後，優化器將根據詳細的成本估計選擇外部和內部表。

然而，現今的關係優化器沒有一個是完美的。所以，DBA 和性能分析人員必須經過評估優化器生成的訪問路徑來審查優化器作出的選擇。這多是一個艱難的過程，由於它涉及到理解數據、統計數據和訪問路徑細節。認真考慮實現最佳性能的組織使用自動化工具來幫助評估其 SQL 的性能。

總結

今天的文章提供了SQL優化和多表訪問路徑的高級視圖。固然，不一樣的 DBMS 有許多複雜的細節，你須要瞭解系統的工做方式，以實現你想要的性能。

經過四部分系列文章的前三部分，咱們已經研究了SQL優化的核心過程，可是還有不少須要學習的地方。在下一期文章中，咱們將介紹一些應該注意的其餘重要SQL優化注意事項。