資料庫的SQL引擎是資料庫重要的子系統之一，它對上負責承接應用程式傳送的SQL語句，對下負責指揮執行器執行執行計劃。其中最佳化器作為SQL引擎中最重要、最複雜的模組，被稱為資料庫的“大腦”，最佳化器產生的執行計劃的優劣直接決定資料庫的效能。

本文從SQL語句開始介紹，對SQL引擎的各個模組進行全面的說明。

一、 SQL引擎概覽

SQL引擎是資料庫系統的重要組成部分，主要職責是將應用程式輸入的SQL語句在當前負載場景下生成高效的執行計劃，在SQL語句的高效執行上扮演重要角色。

SQL語句在SQL引擎中的執行過程如下圖所示。

圖 SQL語句在SQL引擎中的執行流程

從上圖中可以看出，應用程式的SQL語句需要經過SQL解析生成邏輯執行計劃、經過查詢最佳化生成物理執行計劃，然後將物理執行計劃轉交給查詢執行引擎做物理運算元的執行操作。

SQL解析通常包含詞法分析、語法分析、語義分析幾個子模組。SQL是介於關係演算和關係代數之間的一種描述性語言，它吸取了關係代數中一部分邏輯運算元的描述，而放棄了關係代數中“過程化”的部分，SQL解析主要的作用就是將一個SQL語句編譯成為一個由關係運算元組成的邏輯執行計劃。

描述語言的特點是規定了需要獲取的 WHAT，而不關心 HOW，也就是隻關注結果而不關注過程，因此SQL描述性的特點導致查詢最佳化在資料庫管理系統中具有非常重要的作用。

查詢重寫則是在邏輯執行計劃的基礎上進行等價的關係代數變換，這種最佳化也可以稱為代數最佳化，雖然兩個關係代數式獲得的結果完全相同，但是它們的執行代價卻可能有很大的差異，這就構成了查詢重寫最佳化的基礎。

在早期的資料庫管理系統中，通常採用基於啟發式規則的方法來生成最優的物理執行計劃，但是這種基於規則的最佳化的靈活度不夠，常常產生一些次優的執行計劃，而代價估算的引入，則從根本上解決了基於規則最佳化的不足。

基於代價的最佳化器一方面生成“候選”的物理執行路徑，另一方面計算這些執行路徑執行代價，這樣就建立了執行路徑的篩選標準，從而能夠透過比較代價而獲得最優的物理執行計劃。

二、 SQL解析

SQL語句在資料庫管理系統中的編譯過程符合編譯器實現的常規過程，需要進行詞法分析、語法分析和語義分析。

• 詞法分析:從查詢語句中識別出系統支援的關鍵字、識別符號、運算子、終結符等，確定每個詞固有的詞性。
• 語法分析:根據SQL的標準定義語法規則，使用詞法分析中產生的詞去匹配語法規則，如果一個 SQL 語句能夠匹配一個語法規則，則生成對應的抽象語法樹（Abstract Syntax Tree，AST）。
• 語義分析:對語法樹進行有效性檢查，檢查語法樹中對應的表、列、函式、表示式是否有對應的後設資料，將抽象語法樹轉換為邏輯執行計劃(關係代數表示式)。
  在SQL標準中，確定了SQL的關鍵字以及語法規則資訊，SQL 解析器在做詞法分析的過程中會將一個SQL語句根據關鍵字資訊以及間隔資訊劃分為獨立的原子單 位，每個單位以一個詞的方式展現，例如有SQL語句:

SELECT w_name FROM warehouse WHERE w_no = 1;

該SQL語句可以劃分的關鍵字、識別符號、運算子、常量等原子單位如表1所示。

表 詞法分析的特徵

語法分析會根據詞法分析獲得的詞來匹配語法規則，最終生成一個抽象語法樹，
每個詞作為語法樹的葉子節點出現，如下圖所示。

圖 抽象語法樹抽象語法樹表達的語義還僅僅限制在能夠保證應用的SQL語句符合SQL標準的規範，但是對於SQL語句的內在含義還需要做有效性檢查。 - 檢查關係的使用:FROM 子句中出現的關係必須是該查詢對應模式中的關係或檢視。 - 檢查與解析屬性的使用:在SELECT語句中或者WHERE子句中出現的各個屬性必須是FROM子句中某個關係或檢視的屬性。 - 檢查資料型別:所有屬性的資料型別必須是匹配的。在有效性檢查的同時，語義分析的過程還是有效性語義繫結(Bind)的過程，透過語義分析的檢查，抽象語法樹就轉換成一個邏輯執行計劃。邏輯執行計劃可以透過關係代數表示式的形式來表現，如下圖所示。

圖 關係代數表示式

三、查詢最佳化

SQL語句在編寫的過程中，資料庫應用開發人員通常會考慮以不同的形式編寫SQL語句達到提升執行效能的目的。那麼，為什麼還需要查詢最佳化器來對 SQL進行最佳化呢? 這是因為一個應用程式可能會涉及大量的SQL語句，而且有些 SQL語句的邏輯極為複雜，資料庫開發人員很難面面俱到地寫出高效能語句，而查詢最佳化器則具有一些獨特的優勢：

• 查詢最佳化器和資料庫開發人員之間存在資訊不對稱。查詢最佳化器在最佳化的過程中會參考資料庫統計模組自動產生的統計資訊，這些統計資訊從各個角度來描述資料的分佈情況，查詢最佳化器會綜合考慮統計資訊中的各種資料，從而得到一個比較好的執行方案，而資料庫開發人員一方面無法全面地瞭解資料的分佈情況，另一方面也很難透過統計資訊構建一個精確的代價模型對執行計劃進行篩選。
• 查詢最佳化器和資料庫開發人員之間的時效性不同。資料庫中的資料瞬息萬變，一個在 A 時間點執行效能很高的執行計劃，在B時間點由於資料內容發生了變化，它的效能可能就很低，查詢最佳化器則隨時都能根據資料的變化調整執行計劃，而資料庫應用程式開發人員則只能手動地調整SQL語句，和查詢最佳化器相比，它的時效性比較低。
• 查詢最佳化器和資料庫開發人員的計算能力不同。目前計算機的計算能力已經大幅提高，在執行數值計算方面和人腦相比具有巨大的優勢，查詢最佳化器對一個 SQL語句進行最佳化時，可以從成百上千個執行方案中選擇一個最優方案，而人腦要計算這幾百種方案需要的時間要遠遠長於計算機。

因此，查詢最佳化器是提升查詢效率的非常重要的一個手段，雖然一些資料庫也提供了人工干預執行計劃生成的方法，但是通常而言，查詢最佳化器的最佳化過程對資料庫開發人員是透明的，它自動進行邏輯上的等價變換、自動進行物理執行計劃的篩選，極大地提高了資料庫應用程式開發人員的“生產力”。

依據最佳化方法的不同，最佳化器的最佳化技術可以分為：

• RBO(Rule Based Optimization，基於規則的查詢最佳化):根據預定義的啟發式規則對SQL語句進行最佳化。
• CBO(CostBasedOptimization，基於代價的查詢最佳化):對SQL語句對應的待選執行路徑進行代價估算，從待選路徑中選擇代價最低的執行路徑作為最終的執行計劃。
• ABO(AI Based Optimization，基於機器學習的查詢最佳化):收集執行計劃的特徵資訊，藉助機器學習模型獲得經驗資訊，進而對執行計劃進行調優，獲得最優的執行計劃。

在早期的資料庫中，查詢最佳化器通常採用啟發式規則進行最佳化，這種最佳化方式不夠靈活，往往難以獲得最優的執行代價，而基於代價的最佳化則能夠針對大多數場景高效篩選出效能較好的執行計劃，但面對千人千面的使用者和日趨複雜的實際查詢場景，普適性的查詢最佳化難以捕捉到使用者特定的查詢需求、資料分佈、硬體效能等特徵，難以全方位滿足實際的最佳化需求。

近年來 AI技術發展迅速，特別是在深度學習領域。ABO 在建模效率、估算準確率和自適應性等方面都有很大優勢，有望打破 RBO 和 CBO 基於靜態模型的限制。透過對歷史經驗的不斷學習，ABO 將目標場景的模式進行抽象化，形成動態的模型，自適應地針對使用者的實際場景進行最佳化。openGauss採用基於 CBO 的最佳化技術，另外在ABO方面也在進行積極探索。

查詢最佳化的詳細內容將在下一篇內容進行介紹。