如何編寫更好的SQL查詢:終極指南-第一部分

dbasdk發表於2017-09-07

結構化查詢語言(SQL)是資料探勘分析行業不可或缺的一項技能,總的來說,學習這個技能是比較容易的。對於SQL來說,編寫查詢語句只是第一步,確保查詢語句高效並且適合於你的資料庫操作工作,才是最重要的。這個教程將會提供給你一些步驟,來評估你的查詢語句。

  • 首先,應該瞭解學習SQL對於資料探勘分析這個工作的重要性;
  • 接下來,應該先學習SQL查詢語句的處理和執行過程以便可以更好的瞭解到,編寫高質量的查詢有多重要。具體說來就是,應該瞭解查詢是如何被解析、重寫、最佳化和最終評估的;
  • 掌握了上面一點之後,你不僅需要重溫初學者在編寫查詢語句時,所使用的查詢反向模型,而且還需要了解有關可能發生錯誤的替代方案和解決方案。同時還應該瞭解更多查詢工作中的基於集合的程式方法。
  • 在效能方面也需要關注反向模型,除了手動提高SQL查詢的方法外,還需要以更加結構化和深入的方式來分析你的查詢,以便使用其它工具來完成整個查詢工作。
  • 在執行查詢之前,還需要更加深入的瞭解執行查詢計劃的時間複雜度。 
  • 最後,應該瞭解如何進一步的調整你的查詢語句。

 

為什麼要學SQL?

尋找資料探勘分析行業的工作,SQL是最需要的技能之一,不論是申請資料分析工作、資料引擎工作、資料探勘分析或者其它工作。在O'Reilly釋出的《2016資料科學從業者薪酬報告》中,有70%的受訪者證實了這一點,表示他們需要在專業環境中使用SQL。此外,本次調查中,SQL遠勝於R(57%)和Python(54%)等程式語言。所以在資料探勘分析領域,SQL是必備技能。

 

我們分析一下SQL從1970s早期開發出,到現在還經久不衰的原因:

一、公司基本都將資料儲存在關聯式資料庫管理系統(RDBMS)或關係資料流管理系統(RDSMS)中,所以需要使用SQL來實現訪問。SQL是通用的資料語言,可以使用SQL和幾乎其它任何資料庫進行互動,甚至可以在本地建立自己的資料庫!

二、只有少量的SQL實現沒有遵循標準,在供應商之間不相容。因此,瞭解SQL標準是在資料探勘分析行業立足的必要要求。

三、最重要的是SQL也被更新的技術所接受,例如Hive或者Spark SQL。Hive是一個用於查詢和管理大型資料集的類似於SQL的查詢語言介面;Spark SQL可用於執行SQL查詢。

簡而言之,以下就是為什麼你應該學習這種查詢語言:

  • 即使對於新手來說,SQL也很容易學習。學習曲線很平緩,編寫SQ查詢幾乎不花費時間。
  • SQL遵循“學習一次,隨時隨地可用”的原則,所以花費時間學習SQL很划算!
  • SQL是對程式語言的一種極好的補充;在某些情況下,編寫查詢甚至比編寫程式碼更為優先!
  • ...

 

SQL處理和查詢執行

為了提高SQL查詢的效能,首先需要知道,執行查詢時,內部會發生什麼。

以下時查詢執行的過程:

  • 首先,將查詢解析成“解析樹”; 分析查詢是否滿足語法和語義要求。解析器將會建立一個輸入查詢的內部表示,然後將此輸出傳遞給重寫引擎。
  • 然後,最佳化器的任務是為給定的查詢,尋找最佳執行或查詢計劃。執行計劃準確地定義了每個操作所使用的演算法,以及如何協調操作的執行。
  • 最後,為了找到最佳的執行計劃,最佳化器會列舉所有可能的執行計劃,並確定每個計劃的質量或成本,以便獲取有關當前資料庫狀態的資訊,最後選擇最佳的執行計劃。由於查詢最佳化器可能不完善,因此資料庫使用者和管理員有時需要手動檢查並調整最佳化器生成的計劃,以便獲得更好的效能。

現在你已經清楚了什麼才是好的執行計劃。

正如前面瞭解到的,計劃的成本質量起著重要的作用。更具體地說,評估計劃所需的磁碟I / O數量,計劃的CPU花銷以及資料庫客戶端的整體響應時間和總執行時間等因素至關重要。這就是時間複雜性的概念。後面還將繼續瞭解。

接下來,執行所選擇的查詢計劃,由系統的執行引擎進行評估,並返回查詢結果。

 

編寫SQL查詢

需要進一步說明的是,垃圾回收原則(GIGO)原本就是表達在查詢處理和執行之中:制定查詢的人,同時也決定著SQL查詢的效能。

這意味著在編寫查詢,有些事情可以同步去做。就像文章開始時介紹的,編寫查詢需要遵循兩個標準:首先,編寫的查詢需要滿足一定的標準,其次還應該應對查詢中可以出現的效能問題。

總的來說,有四個分句和關鍵字,方便新手考慮效能問題:

  • WHERE 分句
  • INNER JOIN 和 LEFT JOIN 關鍵字
  • HAVING 分句

雖然這種做法簡單而天真,但對於一個初學者來說,這些方法卻是一個很好的指引。這些地方也是你剛開始編寫時,容易發生錯誤的地方,這些錯誤也很難發現。

同時,要想提升效能,使其變得有意義,就不能脫離上下文:在考慮SQL效能時,不能武斷的認為上面的分句和關鍵字不好。使用WHERE 或 HAVING的分句也可能是很好的查詢語句。

透過下面的章節來來進一步瞭解編寫查詢時反向模型和代替方法,並將這些提示和技巧作為指導。如何重寫查詢和是否需要重寫查詢取決於資料量,以及資料庫和執行查詢所需的次數等。這完全取決於你的查詢目標,事先掌握一些有關資料的知識是非常重要的!

1. 僅檢索你需要的資料

在編寫SQL查詢時,並不是資料越多越好。因此在使用SELECT 語句、DISTINCT分句和LIKE運算子時,需要謹慎。

SELECT宣告

在編寫完查詢語句之後,首先需要做的事情就是檢查select語句是否簡潔。你的目標應該是刪除不必要的select列。以便只取到符合你查詢目的的資料。

如果還有相關使用exists的子查詢,那麼就應該在select語句中使用常量,而不是選擇實際列的值。當檢查實體時,這是特別方便的。

請記住,相關子查詢是使用外部查詢中的值的子查詢,並且在這種情況下,NULL是可以作為“常量”的,這點確實令人困惑!

透過以下示例,可以瞭解使用常量的含義:

SELECT driverslicensenr, name FROM Drivers WHERE EXISTS (SELECT '1' FROM Fines WHERE fines.driverslicensenr = drivers.driverslicensenr);

提示:我們很容易發現,使用相關子查詢並不總是一個好主意,所以可以考慮透過以下方式避免使用相關子查詢,例如使用 INNER JOIN重寫:

SELECT driverslicensenr, name FROM drivers INNER JOIN fines ON fines.driverslicensenr = drivers.driverslicensenr;

DISTINCT分句

SELECT DISTINCT 語句用於返回不同的值。 DISTINCT 是一個分句,能不用盡量不用,因為如果將DISTINCT新增到查詢語句中,會導致執行時間的增加 。

LIKE運算子

在查詢中使用LIKE運算子時,如果模式是以% 或_開始,則不會使用索引。它將阻止資料庫使用索引(如果存在的話)。當然,從另一個角度來看,你也可以認為,這種型別的查詢可能會放寬條件,會檢索到許多不一定滿足查詢目標的記錄。

另外,你對儲存在資料中資料的瞭解,可以幫助你制定一個模式,使用該模式可以對所有資料進行正確的過濾,以便查詢到你最想要的資料。

 

2. 縮小查詢結果 

如果無法避免使用 SELECT語句時,可以考慮透過其它方式縮小查詢結果。例如,使用LIMIT 分句和資料型別轉換的方法。

TOPLIMITROWNUM分句

可以在查詢中新增LIMIT或TOP分句,來設定查詢結果的最大行數。下面是一個示例:

SELECT TOP 3 * FROM Drivers;

請注意,你可以進一步指定PERCENT。

例如,如果你想更改查詢的第一行  SELECT TOP 50 PERCENT *。

SELECT driverslicensenr, name FROM Drivers
LIMIT 2;

此外,你還可以新增ROWNUM 分句,相應於在查詢中使用的LIMIT:

SELECT * FROM Drivers WHERE driverslicensenr = 123456 AND ROWNUM <= 3;

 

資料型別轉換

應該使用最小的資料型別,因為小的資料型別更加有效。

當查詢中需要進行資料型別轉化,會增加執行時間,所以儘可能的避免資料型別轉換的發生;

如果不能避免的話,需要謹慎的定義資料型別的轉換。

 

本文是本系列教程的第一篇,後續還有更多《如何編寫更好的SQL查詢》的文章分享給大家,敬請期待。

原文連結:

轉載請註明出自:

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29734436/viewspace-2144643/,如需轉載,請註明出處,否則將追究法律責任。

相關文章