⑴ sql語句解析過程
為了將用戶寫的SQL文本轉化為Oracle認識的且可執行的語句 這個過程就叫做解析過程 解析分為硬解析和軟解析 一條SQL語句在第一次被執行時必須進行硬解析
當客戶端發出一條SQL語句（也可以是一個存儲過程或者一個匿名PL/SQL塊）進入shared pool時（注意 我們從前面已經知道 Oracle對這些SQL不叫做SQL語句 而是稱為游標 因為Oracle在處理SQL時 需要很多相關的輔助信息 這些輔助信息與SQL語句一起組成了游標） Oracle首先將SQL文本轉化為ASCII值 然後根據hash函數計算其對應的hash值（hash_value） 根據計算出的hash值到library cache中找到對應的bucket 然後比較bucket里是否存在該SQL語句
如果不存在 則需要按照我們前面所描述的 獲得shared pool latch 然後在shared pool中的可用chunk鏈表（也就是bucket）上找到一個可用的chunk 之後釋放shared pool latch 在獲得了chunk以後 這塊chunk就可以認為是進入了library cache 接下來 進行硬解析過程 硬解析包括以下幾個步驟
對SQL語句進行文法檢查 看是否有文法錯誤 比如沒有寫from select拼寫錯誤等 如果存在文法錯誤 則退出解析過程
到數據字典里校驗SQL語句涉及的對象和列是否都存在 如果不存在 則退出解析過程 這個過程會載入dictionary cache
將對象進行名稱轉換 比如將同名詞翻譯成實際的對象等 比如select * from t中 t是一個同名詞 指向hr t 於是Oracle將t轉換為hr t 如果轉換失敗 則退出解析過程
檢查發出SQL語句的用戶是否具有訪問SQL語句里所引用的對象的許可權 如果沒有許可權 則退出解析過程
通過優化器創建一個最優的執行計劃 這個過程會根據數據字典里記錄的對象的統計信息 來計算最優的執行計劃 這一步牽涉大量數學運算 是最消耗CPU資源的
將該游標所產生的執行計劃 SQL文本等裝載進library cache的heap中
在硬解析的過程中 進程會一直持有library cache latch 直到硬解析結束為止 硬解析結束以後 會為SQL語句產生兩個游標 一個是父游標 另一個是子游標 父游標里主要包含兩種信息 SQL文本以及優化目標（optimizer goal） 父游標在第一次打開時被鎖定 直到其他所有的session都關閉該游標後才被解鎖 當父游標被鎖定的時候是不能被交換出library cache的 只有在解鎖以後才能被交換出library cache 父游標被交換出內存時 父游標對應的所有子游標也被交換出library cache 子游標包括游標所有的信息 比如具體的執行計劃 綁定變數等 子游標隨時可以被交換出library cache 當子游標被交換出library cache時 Oracle可以利用父游標的信息重新構建出一個子游標來 這個過程叫reload 可以使用下面的方式來確定reload的比率
select *sum(reloads)/sum(pins) Reload_Ratio from v$librarycache;
一個父游標可以對應多個子游標 子游標具體的個數可以從視圖v$sqlarea的version_count欄位體現出來 而每個具體的子游標則全都在視圖v$sql里體現 當具體綁定變數的值與上次綁定變數的值有較大差異（比如上次執行的綁定變數值的長度是 位 而這次執行綁定變數的值的長度是 位）時或者當SQL語句完全相同 但是所引用的表屬於不同的用戶時 都會創建一個新的子游標
如果在bucket中找到了該SQL語句 則說明該SQL語句以前運行過 於是進行軟解析 軟解析是相對於硬解析而言的 如果解析過程中 可以從硬解析的步驟中去掉一個或多個的話 這樣的解析就是軟解析 軟解析分為以下三種類型
第一種是某個session發出的SQL語句與library? cache里其他session發出的SQL語句一致 這時 該解析過程中可以去掉硬解析中的 和 但是仍然要進行硬解析過程中的 也就是表名和列名檢查 名稱轉換和許可權檢查
* 第二種是某個session發出的SQL語句是該session之前發出的曾經執行過的SQL語句 這時 該解析過程中可以去掉硬解析中的 和 這四步 但是仍然要進行許可權檢查 因為可能通過grant改變了該session用戶的許可權
* 第三種是當設置了初始化參數session_cached_cursors時 當某個session第三次執行相同的SQL時 則會把該SQL語句的游標信息轉移到該session的PGA里 這樣 該session以後再執行相同的SQL語句時 會直接從PGA里取出執行計劃 從而跳過硬解析的所有步驟 這種情況下 是最高效的解析方式 但是會消耗很大的內存
我們舉一個例子來說明解析SQL語句的過程 在該測試中 綁定變數名稱相同 但是變數類型不同時 所出現的解析情況 如下所示
首先 執行下面的命令 清空shared pool里所有的SQL語句
SQL> alter system flush shared_pool;
然後 定義一個數值型綁定變數 並為該綁定變數賦一個數值型的值以後 執行具體的查詢語句
SQL> variable v_obj_id number;
SQL> exec :v_obj_id := ;
SQL> select object_id object_name from sharedpool_test
where object_id=:v_obj_id;
OBJECT_ID OBJECT_NAME
AGGXMLIMP
接下來 定義一個字元型的綁定變數 變數名與前面相同 為該綁定變數賦一個字元型的值以後 執行相同的查詢
SQL> variable v_obj_id varchar ( );
SQL> exec :v_obj_id := ;
SQL> select object_id object_name from sharedpool_test
where object_id=:v_obj_id;
OBJECT_ID OBJECT_NAME
AGGXMLIMP
然後我們到視圖v$sqlarea里找到該SQL的父游標的信息 並到視圖v$sql里找該SQL的所有子游標的信息
SQL> select sql_text version_count from v$sqlarea where
sql_text like %sharedpool_test% ;
SQL_TEXT
VERSION_COUNT
select object_id object_name from sharedpool_test where
object_id=:v_obj_id
SQL> select sql_text child_address address from v$sql
where sql_text like %sharedpool_test% ;
SQL_TEXT
CHILD_ADDRESS ADDRESS
select object_id object_name from sharedpool_test where
object_id=:v_obj_id F
B D
select object_id object_name from sharedpool_test where
object_id=:v_obj_id FC
B D
從記錄父游標的視圖v$sqlarea的version_count列可以看到 該SQL語句有 個子游標 而從記錄子游標的視圖v$sql里可以看到 該SQL文本確實有兩條記錄 而且它們的SQL文本所處的地址（ADDRESS列）也是一樣的 但是子地址（CHILD_ADDRESS）卻不一樣 這里的子地址實際就是子游標所對應的heap 的句柄
lishixin/Article/program/Oracle/201311/18653
⑵ MyBatis3源碼解析-執行SQL流程
其實我們有在XML配置文件中配置標簽來載入我們的mapper文件。
官網文檔給了答案：總共有四種方式()。
前文了解了XML 配置解析器XMLConfigBuilder的parse()方法便是載入配置文件生成一個Configuration對象的入口方法；
上篇了解了通過掃描environments標簽如何獲取數據源，下面會執行一個mapperElement方法來解析mappers標簽,root.evalNode("mappers")返回的是一個value是mappers標簽中內容的XNode對象；
進入方法，會有限判斷有沒有package標簽，如何沒有則會去獲取該子node的三個屬性，然後3個if分別處理。
無論是哪種方式最後都會執行MapperBuilderAssistant類中的addMappedStatement方法,之後會將解析的sql信息後封裝成的MappedStatement對象放在全局配置類的一個Map屬性mappedStatements中。
再貼一下我們的測試demo：
在生成SqlSessionFactory對象後，會調用openSession()。已知在前面執行build方法時把數據源和sql都存儲在了全局配置類Configuration中，在該方法中則會從配置類中獲取Environment(其中包含數據源信息)、TransactionFactory(事務)、Executor（執行器）來生成一個默認的DefaultSqlSession對象返回。
Executor（執行器）一共分為三種：簡單、復用、批量，默認SimpleExecutor。CachingExecutor也實現了Executor介面，嚴格來說CachingExecutor不是一個真正的實現，它會委託給BaseExecutor去實現。此處不做細講。
到此我們了解到openSession()方法只是獲取到一些信息，生成了一個執行器，還沒有開始sql執行流程。
接下來測試demo中繼續執行LevelDao = sqlSession.getMapper(LevelDao.class);
則會調用configuration.getMapper(type, this)，繼續調用mapperRegistry.getMapper(type, sqlSession)，其內部是獲取具體Class從MapperRegistry類中的 Map中獲取MapperProxyFactory，該MAP中的元素是我們在執行new SqlSessionFactoryBuilder().build(input)方法掃描mapper標簽時且是package或class的方式存放進去的；
最後通過SqlSession調用MapperProxyFactory類生成了一個代理對象並返回。
我們調用的List all = .findAll(); 實際上最後是會調用這個代理對象MapperProxy中的invoke方法
當我們執行到我們自定義的方法時會執行execute方法，這句最終就會執行增刪改查了；
再往下一層，就是執行JDBC那一套了，獲取鏈接，執行，得到ResultSet，解析ResultSet映射成JavaBean。
最後總結一下具體流程：
⑶ java解析sql語句是實現不了的
哈哈，樓主沒文化了。這個是需要詞法解析和語法解析的。總體的思路是設計一個分詞器，按規則將語句進行分詞。例如，關鍵字用1表示，字元串用2表示，當分詞到 select時，標識1，分詞到'select'時標識為2。然後語法解析器用來分析怎麼樣的詞法組合才合理，需要構造語法樹等。
整體來說還是很復雜的，但是是完全可以實現的。
最後推薦個很好的java實現： JavaCC
⑷ 如何進行SQL語句的解析與改寫
這段代碼看起來有點兒別扭，一般情況下在不進行匯總計算的時候是不會使用group by語句的。
看你的代碼想表達的意思是：從dbo.F4201 表中找出與dbo.F4211_BK_80429_8表中SHDOCO = SDDOCO 並且SHKCOO = SDKCOO並且SHDCTO = SDDCTO的數據記錄，是這個意思嗎？如果是這樣語句可以改寫為如下：
SELECT * FROM dbo.F4201
WHERE exist (
SELECT 1
from dbo.F4211_BK_80429_8
where SHDOCO = SDDOCO
and SHKCOO = SDKCOO
and SHDCTO = SDDCTO
)
⑸ 如何對變異的sql語句做解析處理
優化SQL查詢：如何寫出高性能SQL語句1、首先要搞明白什麼叫執行計劃？執行計劃是資料庫根據SQL語句和相關表的統計信息作出的一個查詢方案，這個方案是由查詢優化器自動分析產生欀如一條SQL語句如果用來從一個10萬條記錄的表中查1條記錄，那查詢優化器會選擇「索引查找」方式，如果該表進行了歸檔，當前只剩下5000條記錄了，那查詢優化器就會改變方案，採用「全表掃描」方式。可見，執行計劃並不是固定的，它是「個性化的」。產生一個正確的「執行計劃」有兩點很重要：(1)SQL語句是否清晰地告訴查詢優化器它想干什麼？(2)查詢優化器得到的資料庫統計信息是否是最新的、正確的？2、統一SQL語句的寫法對於以下兩句SQL語句，程序員認為是相同的，資料庫查詢優化器認為是不同的。select*fromalselect*Fromal其實就是大小寫不同，查詢分析器就認為是兩句不同的SQL語句，必須進行兩次解析。生成2個執行計劃。所以作為程序員，應該保證相同的查詢語句在任何地方都一致，多一個空格都不行！3、不要把SQL語句寫得太復雜我經常看到，從資料庫中捕捉到的一條SQL語句列印出來有2張A4紙這么長。一般來說這么復雜的語句通常都是有問題的。我拿著這2頁長的SQL語句去請教原作者，結果他說時間太長，他一時也看不懂了。可想而知，連原作者都有可能看糊塗的SQL語句，資料庫也一樣會看糊塗。一般，將一個Select語句的結果作為子集，然後從該子集中再進行查詢，這種一層嵌套語句還是比較常見的，但是根據經驗，超過3層嵌套，查詢優化器就很容易給出錯誤的執行計劃。因為它被繞暈了。像這種類似人工智慧的東西，終究比人的分辨力要差些，如果人都看暈了，我可以保證資料庫也會暈的。另外，執行計劃是可以被重用的，越簡單的SQL語句被重用的可能性越高。而復雜的SQL語句只要有一個字元發生變化就必須重新解析，然後再把這一大堆垃圾塞在內存里。可想而知，資料庫的效率會何等低下。4、使用「臨時表」暫存中間結果簡化SQL語句的重要方法就是採用臨時表暫存中間結果，但是，臨時表的好處遠遠不止這些，將臨時結果暫存在臨時表，後面的查詢就在tempdb中了，這可以避免程序中多次掃描主表，也大大減少了程序執行中「共享鎖」阻塞「更新鎖」，減少了阻塞，提高了並發性能。5、OLTP系統SQL語句必須採用綁定變數select*>』2010-10-2000:00:01′select*>』2010-09-2200:00:01′以上兩句語句，查詢優化器認為是不同的SQL語句，需要解析兩次。如果採用綁定變數select*>@chgtime@chgtime變數可以傳入任何值，這樣大量的類似查詢可以重用該執行計劃了，這可以大大降低資料庫解析SQL語句的負擔。一次解析，多次重用，是提高資料庫效率的原則。6、綁定變數窺測事物都存在兩面性，綁定變數對大多數OLTP處理是適用的，但是也有例外。比如在where條件中的欄位是「傾斜欄位」的時候。「傾斜欄位」指該列中的絕大多數的值都是相同的，一張人口調查表，其中「民族」這列，90%以上都是漢族。那麼如果一個SQL語句要查詢30歲的漢族人口有多少，那「民族」這列必然要被放在where條件中。這個時候如果採用綁定變數@nation會存在很大問題。試想如果@nation傳入的第一個值是「漢族」，那整個執行計劃必然會選擇表掃描。然後，第二個值傳入的是「布依族」，按理說「布依族」占的比例可能只有萬分之一，應該採用索引查找。但是，由於重用了第一次解析的「漢族」的那個執行計劃，那麼第二次也將採用表掃描方式。這個問題就是著名的「綁定變數窺測」，建議對於「傾斜欄位」不要採用綁定變數。7、只在必要的情況下才使用begintranSQLServer中一句SQL語句默認就是一個事務，在該語句執行完成後也是默認commit的。其實，這就是begintran的一個最小化的形式，好比在每句語句開頭隱含了一個begintran，結束時隱含了一個commit。有些情況下，我們需要顯式聲明begintran，比如做「插、刪、改」操作需要同時修改幾個表，要求要麼幾個表都修改成功，要麼都不成功。begintran可以起到這樣的作用，它可以把若干SQL語句套在一起執行，最後再一起commit。好處是保證了數據的一致性，但任何事情都不是完美無缺的。Begintran付出的代價是在提交之前，所有SQL語句鎖住的資源都不能釋放，直到commit掉。可見，如果Begintran套住的SQL語句太多，那資料庫的性能就糟糕了。在該大事務提交之前，必然會阻塞別的語句，造成block很多。Begintran使用的原則是，在保證數據一致性的前提下，begintran套住的SQL語句越少越好！有些情況下可以採用觸發器同步數據，不一定要用begintran。8、一些SQL查詢語句應加上nolock在SQL語句中加nolock是提高SQLServer並發性能的重要手段，在oracle中並不需要這樣做，因為oracle的結構更為合理，有undo表空間保存「數據前影」，該數據如果在修改中還未commit，那麼你讀到的是它修改之前的副本，該副本放在undo表空間中。這樣，oracle的讀、寫可以做到互不影響，這也是oracle廣受稱贊的地方。SQLServer的讀、寫是會相互阻塞的，為了提高並發性能，對於一些查詢，可以加上nolock，這樣讀的時候可以允許寫，但缺點是可能讀到未提交的臟數據。使用nolock有3條原則。(1)查詢的結果用於「插、刪、改」的不能加nolock！(2)查詢的表屬於頻繁發生頁分裂的，慎用nolock！(3)使用臨時表一樣可以保存「數據前影」，起到類似oracle的undo表空間的功能，能採用臨時表提高並發性能的，不要用nolock。9、聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂比如訂單表，有訂單編號orderid，也有客戶編號contactid，那麼聚集索引應該加在哪個欄位上呢？對於該表，訂單編號是順序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，這樣不容易經常產生頁分裂。然而，由於大多數查詢都是根據客戶編號來查的，因此，將聚集索引加在contactid上才有意義。而contactid對於訂單表而言，並非順序欄位。比如「張三」的「contactid」是001，那麼「張三」的訂單信息必須都放在這張表的第一個數據頁上，如果今天「張三」新下了一個訂單，那該訂單信息不能放在表的最後一頁，而是第一頁！如果第一頁放滿了呢？很抱歉，該表所有數據都要往後移動為這條記錄騰地方。SQLServer的索引和Oracle的索引是不同的，SQLServer的聚集索引實際上是對表按照聚集索引欄位的順序進行了排序，相當於oracle的索引組織表。SQLServer的聚集索引就是表本身的一種組織形式，所以它的效率是非常高的。也正因為此，插入一條記錄，它的位置不是隨便放的，而是要按照順序放在該放的數據頁，如果那個數據頁沒有空間了，就引起了頁分裂。所以很顯然，聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂。曾經碰到過一個情況，一位哥們的某張表重建索引後，插入的效率大幅下降了。估計情況大概是這樣的。該表的聚集索引可能沒有建在表的順序欄位上，該表經常被歸檔，所以該表的數據是以一種稀疏狀態存在的。比如張三下過20張訂單，而最近3個月的訂單只有5張，歸檔策略是保留3個月數據，那麼張三過去的15張訂單已經被歸檔，留下15個空位，可以在insert發生時重新被利用。在這種情況下由於有空位可以利用，就不會發生頁分裂。但是查詢性能會比較低，因為查詢時必須掃描那些沒有數據的空位。重建聚集索引後情況改變了，因為重建聚集索引就是把表中的數據重新排列一遍，原來的空位沒有了，而頁的填充率又很高，插入數據經常要發生頁分裂，所以性能大幅下降。對於聚集索引沒有建在順序欄位上的表，是否要給與比較低的頁填充率？是否要避免重建聚集索引？是一個值得考慮的問題！10、加nolock後查詢經常發生頁分裂的表，容易產生跳讀或重復讀加nolock後可以在「插、刪、改」的同時進行查詢，但是由於同時發生「插、刪、改」，在某些情況下，一旦該數據頁滿了，那麼頁分裂不可避免，而此時nolock的查詢正在發生，比如在第100頁已經讀過的記錄，可能會因為頁分裂而分到第101頁，這有可能使得nolock查詢在讀101頁時重復讀到該條數據，產生「重復讀」。同理，如果在100頁上的數據還沒被讀到就分到99頁去了，那nolock查詢有可能會漏過該記錄，產生「跳讀」。上面提到的哥們，在加了nolock後一些操作出現報錯，估計有可能因為nolock查詢產生了重復讀，2條相同的記錄去插入別的表，當然會發生主鍵沖突。11、使用like進行模糊查詢時應注意有的時候會需要進行一些模糊查詢比如select*fromcontactwhereusernamelike『%yue%』關鍵詞%yue%，由於yue前面用到了「%」，因此該查詢必然走全表掃描，除非必要，否則不要在關鍵詞前加%，12、數據類型的隱式轉換對查詢效率的影響sqlserver2000的資料庫一的程序在提交sql語句的時候，沒有使用強類型提交這個欄位的值，由sqlserver2000自動轉換數據類型，會導致傳入的參數與主鍵欄位類型不一致，這個時候sqlserver2000可能就會使用全表掃描。Sql2005上沒有發現這種問題，但是還是應該注意一下。13、SQLServer表連接的三種方式(1)MergeJoin(2)NestedLoopJoin(3)HashJoinSQLServer2000隻有一種join方式——NestedLoopJoin，如果A結果集較小，那就默認作為外表，A中每條記錄都要去B中掃描一遍，實際掃過的行數相當於A結果集行數xB結果集行數。所以如果兩個結果集都很大，那Join的結果很糟糕。SQLServer2005新增了MergeJoin，如果A表和B表的連接欄位正好是聚集索引所在欄位，那麼表的順序已經排好，只要兩邊拼上去就行了，這種join的開銷相當於A表的結果集行數加上B表的結果集行數，一個是加，一個是乘，可見mergejoin的效果要比NestedLoopJoin好多了。如果連接的欄位上沒有索引，那SQL2000的效率是相當低的，而SQL2005提供了Hashjoin，相當於臨時給A，B表的結果集加上索引，因此SQL2005的效率比SQL2000有很大提高，我認為，這是一個重要的原因。總結一下，在表連接時要注意以下幾點：(1)連接欄位盡量選擇聚集索引所在的欄位(2)仔細考慮where條件，盡量減小A、B表的結果集(3)如果很多join的連接欄位都缺少索引，而你還在用SQLServer2000，趕緊升級吧。
⑹ SQL語句執行過程詳解
SQL語句執行過程詳解
一條sql，plsql的執行到底是怎樣執行的呢？
一、SQL語句執行原理：
第一步:客戶端把語句發給伺服器端執行當我們在客戶端執行 select 語句時,客戶端會把這條 SQL 語句發送給伺服器端,讓伺服器端的
進程來處理這語句。也就是說,Oracle 客戶端是不會做任何的操作,他的主要任務就是把客戶端產生
的一些 SQL 語句發送給伺服器端。雖然在客戶端也有一個資料庫進程,但是,這個進程的作用跟伺服器
上的進程作用事不相同的。伺服器上的資料庫進程才會對SQL 語句進行相關的處理。不過,有個問題需
要說明,就是客戶端的進程跟伺服器的進程是一一對應的。也就是說,在客戶端連接上伺服器後,在客戶
端與伺服器端都會形成一個進程,客戶端上的我們叫做客戶端進程;而伺服器上的我們叫做伺服器進程。
第二步:語句解析
當客戶端把 SQL 語句傳送到伺服器後,伺服器進程會對該語句進行解析。同理,這個解析的工作,
也是在伺服器端所進行的。雖然這只是一個解析的動作,但是,其會做很多「小動作」。
1. 查詢高速緩存(library cache)。伺服器進程在接到客戶端傳送過來的 SQL 語句時,不
會直接去資料庫查詢。而是會先在資料庫的高速緩存中去查找,是否存在相同語句的執行計劃。如果在
數據高速緩存中,則伺服器進程就會直接執行這個 SQL 語句,省去後續的工作。所以,採用高速數據緩
存的話,可以提高 SQL 語句的查詢效率。一方面是從內存中讀取數據要比從硬碟中的數據文件中讀取
數據效率要高,另一方面,也是因為這個語句解析的原因。
不過這里要注意一點,這個數據緩存跟有些客戶端軟體的數據緩存是兩碼事。有些客戶端軟體為了
提高查詢效率,會在應用軟體的客戶端設置數據緩存。由於這些數據緩存的存在,可以提高客戶端應用軟
件的查詢效率。但是,若其他人在伺服器進行了相關的修改,由於應用軟體數據緩存的存在,導致修改的
數據不能及時反映到客戶端上。從這也可以看出,應用軟體的數據緩存跟資料庫伺服器的高速數據緩存
不是一碼事。
2. 語句合法性檢查(data dict cache)。當在高速緩存中找不到對應的 SQL 語句時,則服
務器進程就會開始檢查這條語句的合法性。這里主要是對 SQL 語句的語法進行檢查,看看其是否合乎
語法規則。如果伺服器進程認為這條 SQL 語句不符合語法規則的時候,就會把這個錯誤信息,反饋給客
戶端。在這個語法檢查的過程中,不會對 SQL 語句中所包含的表名、列名等等進行 SQL 他只是語法
上的檢查。
3. 語言含義檢查(data dict cache)。若 SQL 語句符合語法上的定義的話,則伺服器進程
接下去會對語句中的欄位、表等內容進行檢查。看看這些欄位、表是否在資料庫中。如果表名與列名不
准確的話,則資料庫會就會反饋錯誤信息給客戶端。所以,有時候我們寫 select 語句的時候,若語法
與表名或者列名同時寫錯的話,則系統是先提示說語法錯誤,等到語法完全正確後,再提示說列名或表名
錯誤。
4. 獲得對象解析鎖(control structer)。當語法、語義都正確後,系統就會對我們需要查詢
的對象加鎖。這主要是為了保障數據的一致性,防止我們在查詢的過程中,其他用戶對這個對象的結構發
生改變。
5. 數據訪問許可權的核對(data dict cache)。當語法、語義通過檢查之後,客戶端還不一定
能夠取得數據。伺服器進程還會檢查,你所連接的用戶是否有這個數據訪問的許可權。若你連接上伺服器
的用戶不具有數據訪問許可權的話,則客戶端就不能夠取得這些數據。有時候我們查詢數據的時候,辛辛苦
苦地把 SQL 語句寫好、編譯通過,但是,最後系統返回個 「沒有許可權訪問數據」的錯誤信息,讓我們氣
半死。這在前端應用軟體開發調試的過程中,可能會碰到。所以,要注意這個問題,資料庫伺服器進程先
檢查語法與語義,然後才會檢查訪問許可權。
6. 確定最佳執行計劃 ?。當語句與語法都沒有問題,許可權也匹配的話,伺服器進程還是不會直接對
資料庫文件進行查詢。伺服器進程會根據一定的規則,對這條語句進行優化。不過要注意,這個優化是有
限的。一般在應用軟體開發的過程中,需要對資料庫的 sql 語言進行優化,這個優化的作用要大大地大
於伺服器進程的自我優化。所以,一般在應用軟體開發的時候,資料庫的優化是少不了的。當伺服器進程
的優化器確定這條查詢語句的最佳執行計劃後,就會將這條 SQL 語句與執行計劃保存到數據高速緩存
(library cache)。如此的話,等以後還有這個查詢時,就會省略以上的語法、語義與許可權檢查的步驟,
而直接執行 SQL 語句,提高 SQL 語句處理效率。
第三步:語句執行
語句解析只是對 SQL 語句的語法進行解析,以確保伺服器能夠知道這條語句到底表達的是什麼意
思。等到語句解析完成之後,資料庫伺服器進程才會真正的執行這條 SQL 語句。這個語句執行也分兩
種情況。
一是若被選擇行所在的數據塊已經被讀取到數據緩沖區的話,則伺服器進程會直接把這個數據傳遞
給客戶端,而不是從資料庫文件中去查詢數據。
若數據不在緩沖區中,則伺服器進程將從資料庫文件中查詢相關數據,並把這些數據放入到數據緩沖
區中(buffer cache)。
第四步:提取數據
當語句執行完成之後,查詢到的數據還是在伺服器進程中,還沒有被傳送到客戶端的用戶進程。所以,
在伺服器端的進程中,有一個專門負責數據提取的一段代碼。他的作用就是把查詢到的數據結果返回給
用戶端進程,從而完成整個查詢動作。從這整個查詢處理過程中,我們在資料庫開發或者應用軟體開發過
程中,需要注意以下幾點:
一是要了解資料庫緩存跟應用軟體緩存是兩碼事情。資料庫緩存只有在資料庫伺服器端才存在,在
客戶端是不存在的。只有如此,才能夠保證資料庫緩存中的內容跟資料庫文件的內容一致。才能夠根據
相關的規則,防止數據臟讀、錯讀的發生。而應用軟體所涉及的數據緩存,由於跟資料庫緩存不是一碼事
情,所以,應用軟體的數據緩存雖然可以提高數據的查詢效率,但是,卻打破了數據一致性的要求,有時候
會發生臟讀、錯讀等情況的發生。所以,有時候,在應用軟體上有專門一個功能,用來在必要的時候清除
數據緩存。不過,這個數據緩存的清除,也只是清除本機上的數據緩存,或者說,只是清除這個應用程序
的數據緩存,而不會清除資料庫的數據緩存。
二是絕大部分 SQL 語句都是按照這個處理過程處理的。我們 DBA 或者基於 Oracle 資料庫的
開發人員了解這些語句的處理過程,對於我們進行涉及到 SQL 語句的開發與調試,是非常有幫助的。有
時候,掌握這些處理原則,可以減少我們排錯的時間。特別要注意,資料庫是把數據查詢許可權的審查放在
語法語義的後面進行檢查的。所以,有時會若光用資料庫的許可權控制原則,可能還不能滿足應用軟體許可權
控制的需要。此時,就需要應用軟體的前台設置,實現許可權管理的要求。而且,有時應用資料庫的許可權管
理,也有點顯得繁瑣,會增加伺服器處理的工作量。因此,對於記錄、欄位等的查詢許可權控制,大部分程
序涉及人員喜歡在應用程序中實現,而不是在資料庫上實現。
DBCC DROPCLEANBUFFERS
從緩沖池中刪除所有清除緩沖區。
DBCC FREEPROCCACHE
從過程緩存中刪除所有元素。
DBCC FREESYSTEMCACHE
從所有緩存中釋放所有未使用的緩存條目
SQL語句中的函數、關鍵字、排序等執行順序:
1. FROM 子句返回初始結果集。
2. WHERE 子句排除不滿足搜索條件的行。
3. GROUP BY 子句將選定的行收集到 GROUP BY 子句中各個唯一值的組中。
4. 選擇列表中指定的聚合函數可以計算各組的匯總值。
5. 此外,HAVING 子句排除不滿足搜索條件的行。
6. 計算所有的表達式;
7. 使用 order by 對結果集進行排序。
8. 查找你要搜索的欄位。
二、SQL語句執行完整過程：
1.用戶進程提交一個 sql 語句:
update temp set a=a*2，給伺服器進程。
2.伺服器進程從用戶進程把信息接收到後,在 PGA 中就要此進程分配所需內存,存儲相關的信息,如在會
話內存存儲相關的登錄信息等。
3.伺服器進程把這個 sql 語句的字元轉化為 ASCII 等效數字碼,接著這個 ASCII 碼被傳遞給一個
HASH 函數,並返回一個 hash 值,然後伺服器進程將到shared pool 中的 library cache 中去查找是否存在相
同的 hash 值,如果存在,伺服器進程將使用這條語句已高速緩存在 SHARED POOL 的library cache 中的已
分析過的版本來執行。
4.如果不存在,伺服器進程將在 CGA 中,配合 UGA 內容對 sql,進行語法分析,首先檢查語法的正確性,接
著對語句中涉及的表,索引,視圖等對象進行解析,並對照數據字典檢查這些對象的名稱以及相關結構，並根據
ORACLE 選用的優化模式以及數據字典中是否存在相應對象的統計數據和是否使用了存儲大綱來生成一個
執行計劃或從存儲大綱中選用一個執行計劃,然後再用數據字典核對此用戶對相應對象的執行許可權,最後生成
一個編譯代碼。
5.ORACLE 將這條 sql 語句的本身實際文本、HASH 值、編譯代碼、與此語名相關聯的任何統計數據
和該語句的執行計劃緩存在 SHARED POOL 的 library cache中。伺服器進程通過 SHARED POOL 鎖存
器(shared pool latch)來申請可以向哪些共享 PL/SQL 區中緩存這此內容,也就是說被SHARED POOL 鎖存
器鎖定的 PL/SQL 區中的塊不可被覆蓋,因為這些塊可能被其它進程所使用。
6.在 SQL 分析階段將用到 LIBRARY
CACHE,從數據字典中核對表、視圖等結構的時候,需要將數據
字典從磁碟讀入 LIBRARY
CACHE,因此,在讀入之前也要使用LIBRARY
CACHE 鎖存器(library cache
pin,library cache lock)來申請用於緩存數據字典。 到現在為止,這個 sql 語句已經被編譯成可執行的代碼了,
但還不知道要操作哪些數據,所以伺服器進程還要為這個 sql 准備預處理數據。
7.首先伺服器進程要判斷所需數據是否在 db buffer 存在,如果存在且可用,則直接獲取該數據,同時根據
LRU 演算法增加其訪問計數;如果 buffer 不存在所需數據,則要從數據文件上讀取首先伺服器進程將在表頭部
請求 TM 鎖(保證此事務執行過程其他用戶不能修改表的結構),如果成功加 TM 鎖,再請求一些行級鎖(TX
鎖),如果 TM、TX 鎖都成功加鎖,那麼才開始從數據文件讀數據,在讀數據之前,要先為讀取的文件准備好
buffer 空間。伺服器進程需要掃面 LRU list 尋找 free db buffer,掃描的過程中,伺服器進程會把發現的所有
已經被修改過的 db buffer 注冊到 dirty list 中, 這些 dirty buffer 會通過 dbwr 的觸發條件,隨後會被寫出到
數據文件,找到了足夠的空閑 buffer,就可以把請求的數據行所在的數據塊放入到 db buffer 的空閑區域或者
覆蓋已經被擠出 LRU list 的非臟數據塊緩沖區,並排列在 LRU list 的頭部,也就是在數據塊放入 DB
BUFFER 之前也是要先申請 db buffer 中的鎖存器,成功加鎖後,才能讀數據到 db buffer。
8.記日誌 現在數據已經被讀入到 db buffer 了,現在伺服器進程將該語句所影響的並被讀
入 db buffer 中的這些行數據的 rowid 及要更新的原值和新值及 scn 等信息從 PGA 逐條的寫入 redo log
buffer 中。在寫入 redo log buffer 之前也要事先請求 redo log buffer 的鎖存器,成功加鎖後才開始寫入,當
寫入達到 redo log buffer 大小的三分之一或寫入量達到 1M 或超過三秒後或發生檢查點時或者 dbwr 之前
發生,都會觸發 lgwr 進程把 redo log buffer 的數據寫入磁碟上的 redo file 文件中(這個時候會產生log file
sync 等待事件)
已經被寫入 redofile 的 redo log buffer 所持有的鎖存器會被釋放,並可被後來的寫入信息覆蓋,
redo log buffer是循環使用的。Redo file 也是循環使用的,當一個 redo file 寫滿後,lgwr 進程會自動切換到
下一 redo file(這個時候可能出現 log fileswitch(checkpoint complete)等待事件)。如果是歸檔模式,歸檔進
程還要將前一個寫滿的 redo file 文件的內容寫到歸檔日誌文件中(這個時候可能出現 log file
switch(archiving needed)。
9.為事務建立回滾段 在完成本事務所有相關的 redo log buffer 之後,伺服器進程開始改寫這個 db buffer
的塊頭部事務列表並寫入 scn,然後 包含這個塊的頭部事務列表及 scn 信息的數據副本放入回滾段中,將
這時回滾段中的信息稱為數據塊的「前映像「,這個」前映像「用於以後的回滾、恢復和一致性讀。(回滾段可以
存儲在專門的回滾表空間中,這個表空間由一個或多個物理文件組成,並專用於回滾表空間,回滾段也可在其它
表空間中的數據文件中開辟。
10.本事務修改數據塊 准備工作都已經做好了,現在可以改寫 db buffer 塊的數據內容了,並在塊的頭部寫
入回滾段的地址。
11.放入 dirty list 如果一個行數據多次 update 而未 commit,則在回滾段中將會有多個「前映像「,除了第
一個」前映像「含有 scn 信息外,其他每個「前映像「的頭部都有 scn 信息和「前前映像」回滾段地址。一個
update 只對應一個 scn,然後伺服器進程將在 dirty list 中建立一
條指向此 db buffer 塊的指針(方便 dbwr 進程可以找到 dirty list 的 db buffer 數據塊並寫入數據文件中)。
接著伺服器進程會從數據文件中繼續讀入第二個數據塊,重復前一數據塊的動作,數據塊的讀入、記日誌、建
立回滾段、修改數據塊、放入 dirty list。當 dirty queue 的長度達到閥值(一般是 25%),伺服器進程將通知
dbwr 把臟數據寫出,就是釋放 db buffer 上的鎖存器,騰出更多的 free db buffer。前面一直都是在說明
oracle 一次讀一個數據塊,其實 oracle 可以一次讀入多個數據塊(db_file_multiblock_read_count 來設置一
次讀入塊的個數)
說明:
在預處理的數據已經緩存在 db buffer 或剛剛被從數據文件讀入到 db buffer 中,就要根據 sql 語句
的類型來決定接下來如何操作。
1>如果是 select 語句,則要查看 db buffer 塊的頭部是否有事務,如果有事務,則從回滾段中讀取數據;如
果沒有事務,則比較 select 的 scn 和 db buffer 塊頭部的 scn,如果前者小於後者,仍然要從回滾段中讀取數據;
如果前者大於後者,說明這是一非臟緩存,可以直接讀取這個 db buffer 塊的中內容。
2>如果是 DML 操作,則即使在 db buffer 中找到一個沒有事務,而且 SCN 比自己小的非臟
緩存數據塊,伺服器進程仍然要到表的頭部對這條記錄申請加鎖,加鎖成功才能進行後續動作,如果不成功,則要
等待前面的進程解鎖後才能進行動作(這個時候阻塞是 tx 鎖阻塞)。
用戶 commit 或 rollback 到現在為止,數據已經在 db buffer 或數據文件中修改完
成,但是否要永久寫到數文件中,要由用戶來決定 commit(保存更改到數據文件) rollback 撤銷數據的更改)。
1.用戶執行 commit 命令
只有當 sql 語句所影響的所有行所在的最後一個塊被讀入 db buffer 並且重做信息被寫入 redo log
buffer(僅指日誌緩沖區,而不包括日誌文件)之後,用戶才可以發去 commit 命令,commit 觸發 lgwr 進程,但不
強制立即 dbwr來釋放所有相應 db buffer 塊的鎖(也就是no-force-at-commit,即提交不強制寫),也就是說有
可能雖然已經 commit 了,但在隨後的一段時間內 dbwr 還在寫這條 sql 語句所涉及的數據塊。表頭部的行鎖
並不在 commit 之後立即釋放,而是要等 dbwr 進程完成之後才釋放,這就可能會出現一個用戶請求另一用戶
已經 commit 的資源不成功的現象。
A .從 Commit 和 dbwr 進程結束之間的時間很短,如果恰巧在 commit 之後,dbwr 未結束之前斷電,因為
commit 之後的數據已經屬於數據文件的內容,但這部分文件沒有完全寫入到數據文件中。所以需要前滾。由
於 commit 已經觸發 lgwr,這些所有未來得及寫入數據文件的更改會在實例重啟後,由 smon 進程根據重做日
志文件來前滾,完成之前 commit 未完成的工作(即把更改寫入數據文件)。
B.如果未 commit 就斷電了,因為數據已經在 db buffer 更改了,沒有 commit,說明這部分數據不屬於數
據文件,由於 dbwr 之前觸發 lgwr 也就是只要數據更改,(肯定要先有 log) 所有 DBWR,在數據文件上的修改
都會被先一步記入重做日誌文件,實例重啟後,SMON 進程再根據重做日誌文件來回滾。
其實 smon 的前滾回滾是根據檢查點來完成的,當一個全部檢查點發生的時候,首先讓 LGWR 進程將
redo log buffer 中的所有緩沖(包含未提交的重做信息)寫入重做日誌文件,然後讓 dbwr 進程將 db buffer 已
提交的緩沖寫入數據文件(不強制寫未提交的)。然後更新控制文件和數據文件頭部的 SCN,表明當前資料庫
是一致的,在相鄰的兩個檢查點之間有很多事務,有提交和未提交的。
像前面的前滾回滾比較完整的說法是如下的說明:
A.發生檢查點之前斷電,並且當時有一個未提交的改變正在進行,實例重啟之後,SMON 進程將從上一個
檢查點開始核對這個檢查點之後記錄在重做日誌文件中已提交的和未提交改變,因為
dbwr 之前會觸發 lgwr,所以 dbwr 對數據文件的修改一定會被先記錄在重做日誌文件中。因此,斷電前被
DBWN 寫進數據文件的改變將通過重做日誌文件中的記錄進行還原,叫做回滾,
B. 如果斷電時有一個已提交,但 dbwr 動作還沒有完全完成的改變存在,因為已經提交,提交會觸發 lgwr
進程,所以不管 dbwr 動作是否已完成,該語句將要影響的行及其產生的結果一定已經記錄在重做日誌文件中
了,則實例重啟後,SMON 進程根據重做日誌文件進行前滾.
實例失敗後用於恢復的時間由兩個檢查點之間的間隔大小來決定,可以通個四個參數設置檢查點執行的頻
率:
Log_checkpoint_interval:
決定兩個檢查點之間寫入重做日誌文件的系統物理塊(redo blocks)
的大小,默認值是 0,無限制。
log_checkpoint_timeout:
兩 個 檢 查 點 之 間 的 時 間 長 度（秒）默 認 值 1800s。
fast_start_io_target:
決定了用於恢復時需要處理的塊的多少,默認值是 0,無限制。
fast_start_mttr_target:
直接決定了用於恢復的時間的長短,默認值是 0,無限制(SMON 進程執行的前滾
和回滾與用戶的回滾是不同的,SMON 是根據重做日誌文件進行前滾或回滾,而用戶的回滾一定是根據回滾段
的內容進行回滾的。
在這里要說一下回滾段存儲的數據,假如是 delete 操作,則回滾段將會記錄整個行的數據,假如是 update,
則回滾段只記錄被修改了的欄位的變化前的數據(前映像),也就是沒有被修改的欄位是不會被記錄的,假如是
insert,則回滾段只記錄插入記錄的 rowid。 這樣假如事務提交,那回滾段中簡單標記該事務已經提交;假如是
回退,則如果操作是 delete,回退的時候把回滾段中數據重新寫回數據塊,操作如果是 update,則把變化前數據
修改回去,操作如果是 insert,則根據記錄的 rowid 把該記錄刪除。
2.如果用戶 rollback。
則伺服器進程會根據數據文件塊和 DB BUFFER 中塊的頭部的事務列表和 SCN 以及回滾段地址找到
回滾段中相應的修改前的副本,並且用這些原值來還原當前數據文件中已修改但未提交的改變。如果有多個
「前映像」,伺服器進程會在一個「前映像」的頭部找到「前前映像」的回滾段地址,一直找到同一事務下的最早的
一個「前映像」為止。一旦發出了 COMMIT,用戶就不能rollback,這使得 COMMIT 後 DBWR 進程還沒有
全部完成的後續動作得到了保障。到現在為例一個事務已經結束了。
說明:
TM 鎖:
符合 lock 機制的,用於保護對象的定義不被修改。 TX 鎖:
這個鎖代表一個事務,是行
級鎖,用數據塊頭、數據記錄頭的一些欄位表示,也是符合 lock 機制,有 resource structure、lock
structure、enqueue 演算法。
⑺ 怎麼用正則表達式解析sql語句
先看要解析的樣例SQL語句：
select * from al
SELECT * frOm al
Select C1,c2 From tb
select c1,c2 from tb
select count(*) from t1
select c1,c2,c3 from t1 where condi1=1
Select c1,c2,c3 From t1 Where condi1=1
select c1,c2,c3 from t1,t2 where condi3=3 or condi4=5 order by o1,o2
Select c1,c2,c3 from t1,t2 Where condi3=3 or condi4=5 Order by o1,o2
select c1,c2,c3 from t1,t2,t3 where condi1=5 and condi6=6 or condi7=7 group by g1,g2
Select c1,c2,c3 From t1,t2,t3 Where condi1=5 and condi6=6 or condi7=7 Group by g1,g2
Select c1,c2,c3 From t1,t2,t3 Where condi1=5 and condi6=6 or condi7=7 Group by g1,g2,g3 order by g2,g3
解析效果之一（isSingleLine=false）：
原SQL為select * from al
解析後的SQL為
select
*
from
al
原SQL為SELECT * frOm al
解析後的SQL為
select
*
from
al
原SQL為Select C1,c2 From tb
解析後的SQL為
select
C1,c2
from
tb
原SQL為select c1,c2 from tb
解析後的SQL為
select
c1,c2
from
tb
原SQL為select count(*) from t1
解析後的SQL為
select
count(*)
from
t1
原SQL為select c1,c2,c3 from t1 where condi1=1
解析後的SQL為
select
c1,c2,c3
from
t1
where
condi1=1
原SQL為Select c1,c2,c3 From t1 Where condi1=1
解析後的SQL為
select
c1,c2,c3
from
t1
where
condi1=1
原SQL為select c1,c2,c3 from t1,t2 where condi3=3 or condi4=5 order by o1,o2
解析後的SQL為
select
c1,c2,c3
from
t1,t2
where
condi3=3 or condi4=5
order by
o1,o2
原SQL為Select c1,c2,c3 from t1,t2 Where condi3=3 or condi4=5 Order by o1,o2
解析後的SQL為
select
c1,c2,c3
from
t1,t2
where
condi3=3 or condi4=5
order by
o1,o2
原SQL為select c1,c2,c3 from t1,t2,t3 where condi1=5 and condi6=6 or condi7=7 group by g1,g2
解析後的SQL為
select
c1,c2,c3
from
t1,t2,t3
where
condi1=5 and condi6=6 or condi7=7
group by
g1,g2
原SQL為Select c1,c2,c3 From t1,t2,t3 Where condi1=5 and condi6=6 or condi7=7 Group by g1,g2
解析後的SQL為
select
c1,c2,c3
from
t1,t2,t3
where
condi1=5 and condi6=6 or condi7=7
group by
g1,g2
原SQL為Select c1,c2,c3 From t1,t2,t3 Where condi1=5 and condi6=6 or condi7=7 Group by g1,g2,g3 order by g2,g3
解析後的SQL為
select
c1,c2,c3
from
t1,t2,t3
where
condi1=5 and condi6=6 or condi7=7
group by
g1,g2,g3
order by
g2,g3
解析效果之二（isSingleLine=true）：
原SQL為select * from al
解析後的SQL為
select
*
from
al
原SQL為SELECT * frOm al
解析後的SQL為
select
*
from
al
原SQL為Select C1,c2 From tb
解析後的SQL為
select
C1,
c2
from
tb
原SQL為select c1,c2 from tb
解析後的SQL為
select
c1,
c2
from
tb
原SQL為select count(*) from t1
解析後的SQL為
select
count(*)
from
t1
原SQL為select c1,c2,c3 from t1 where condi1=1
解析後的SQL為
select
c1,
c2,
c3
from
t1
where
condi1=1
原SQL為Select c1,c2,c3 From t1 Where condi1=1
解析後的SQL為
select
c1,
c2,
c3
from
t1
where
condi1=1
原SQL為select c1,c2,c3 from t1,t2 where condi3=3 or condi4=5 order by o1,o2
解析後的SQL為
select
c1,
c2,
c3
from
t1,
t2
where
condi3=3 or
condi4=5
order by
o1,
o2
原SQL為Select c1,c2,c3 from t1,t2 Where condi3=3 or condi4=5 Order by o1,o2
解析後的SQL為
select
c1,
c2,
c3
from
t1,
t2
where
condi3=3 or
condi4=5
order by
o1,
o2
原SQL為select c1,c2,c3 from t1,t2,t3 wher www.hnne.com e condi1=5 and condi6=6 or condi7=7 group by g1,g2
解析後的SQL為
select
c1,
c2,
c3
from
t1,
t2,
t3
where
condi1=5 and
condi6=6 or
condi7=7
group by
g1,
g2
原SQL為Select c1,c2,c3 From t1,t2,t3 Where condi1=5 and condi6=6 or condi7=7 Group by g1,g2
解析後的SQL為
select
c1,
c2,
c3
from
t1,
t2,
t3
where
condi1=5 and
condi6=6 or
condi7=7
group by
g1,
g2
原SQL為Select c1,c2,c3 From t1,t2,t3 Where condi1=5 and condi6=6 or condi7=7 Group by g1,g2,g3 order by g2,g3
解析後的SQL為
select
c1,
c2,
c3
from
t1,
t2,
t3
where
condi1=5 and
condi6=6 or
condi7=7
group by
g1,
g2,
g3
order by
g2,
g3
使用的類SqlParser，你可以拷貝下來使用之：
package com.sitinspring.common.sqlFormatter;
import java.util.ArrayList;
import java.util.List;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
/**
* SQL語句解析器類
* @author: sitinspring([email protected])
* @date: 2008-3-12
*/
public class SqlParser{
/**
* 逗號
*/
private static final String Comma = ",";
/**
* 四個空格
*/
private static final String FourSpace = " ";
/**
* 是否單行顯示欄位，表，條件的標識量
*/
private static boolean isSingleLine=true;
/**
* 待解析的SQL語句
*/
private String sql;
/**
* SQL中選擇的列
*/
private String cols;
/**
* SQL中查找的表
*/
private String tables;
/**
* 查找條件
*/
private String conditions;
/**
* Group By的欄位
*/
private String groupCols;
/**
* Order by的欄位
*/
private String orderCols;
/**
* 構造函數
* 功能：傳入構造函數，解析成欄位，表，條件等
* @param sql：傳入的SQL語句
*/
public SqlParser(String sql){
this.sql=sql.trim();
⑻ impala怎麼解析sql語句
Impala的SQL解析與執行計劃生成部分是由impala-frontend（Java）實現的，監聽埠是21000。用戶通過Beeswax介面BeeswaxService.query()提交一個請求，在impalad端的處理邏輯是由void ImpalaServer::query(QueryHandle& query_handle, const Query& query)這個函數（在impala-beeswax-server.cc中實現）完成的。
在impala中一條SQL語句先後經歷BeeswaxService.Query->TClientRequest->TExecRequest，最後把TExecRequest交由impala-coordinator分發給多個backend處理。本文主要講一條SQL語句是怎麼一步一步變成TExecRequest的。
本文以下內容都以這樣的一個SQL為例說明：
select jobinfo.dt,user,
max(taskinfo.finish_time-taskinfo.start_time),
max(jobinfo.finish_time-jobinfo.submit_time)
from taskinfo join jobinfo on jobinfo.jobid=taskinfo.jobid
where jobinfo.job_status='SUCCESS' and taskinfo.task_status='SUCCESS'
group by jobinfo.dt,user
通過調用Status ImpalaServer::GetExecRequest(const TClientRequest& request, TExecRequest* result) 函數把TClientRequest轉化成TExecRequest
在這個函數里通過JNI介面調用frontend.createExecRequest()生成TExecRequest。首先調用AnalysisContext.analyze(String stmt)分析提交的SQL語句。
注釋：Analyzer對象是個存放這個SQL所涉及到的所有信息（包含Table, conjunct, slot，slotRefMap， eqJoinConjuncts等）的知識庫，所有跟這個SQL有關的東西都會存到Analyzer對象裡面。
1，SQL的詞法分析，語法分析
AnalysisContext.analyze(String stmt)會調用SelectStmt.analyze()函數，這個函數就是對SQL的analyze和向中央知識庫Analyzer register各種信息。
(1)處理這個SQL所涉及到的Table（即TableRefs），這些Table是在from從句中提取出來的（包含關鍵字from, join, on/using）。注意JOIN操作以及on/using條件是存儲在參與JOIN操作的右邊的表的TableRef中並分析的。依次analyze()每個TableRef，向Analyzer注冊registerBaseTableRef(填充TupleDescriptor)。如果對應的TableRef涉及到JOIN操作，還要analyzeJoin()。在analyzeJoin()時會向Analyzer registerConjunct()填充Analyzer的一些成員變數：conjuncts，tuplePredicates（TupleId與conjunct的映射），slotPredicates（SlotId與conjunct的映射），eqJoinConjuncts。本例中on從句是一種BinaryPredicate，然後onClause.analyze(analyzer)會遞歸analyze這個on從句里的各種組件。
(2)處理select從句(包含關鍵字select, MAX(), AVG()等聚集函數)：分析這個SQL都select了哪幾項，每一項都是個Expr類型的子類對象，把這幾項填入resultExprs數組和colLabels。然後把resultExprs裡面的Expr都遞歸analyze一下，要分析到樹的最底層，向Analyzer注冊SlotRef等。
(3)分析where從句（關鍵字where），首先遞歸Analyze從句中Expr組成的樹，然後向Analyzer registerConjunct()填充Analyzer的一些成員變數(同1，此外還要填充whereClauseConjuncts) 。
(4)處理sort相關信息(關鍵字order by)。先是解析aliases和ordinals，然後從order by後面的從句中提取Expr填入orderingExprs，接著遞歸Analyze從句中Expr組成的樹，最後創建SortInfo對象。
(5)處理aggregation相關信息（關鍵字group by, having, avg, max等）。首先遞歸分析group by從句里的Expr，然後如果有having從句就像where從句一樣，先是analyze having從句中Expr組成的樹，然後向Analyzer registerConjunct()等。
(6)處理InlineView。
關於SQL解析中所涉及到的各種數據結構表示如下：
至此詞法分析，語法分析結束，有點像一個小的編譯器。我們現在回到frontend.createExecRequest()函數中。調用完AnalysisContext.analyze()之後，就開始填充TExecRequest內的成員變數。
(1)如果是DDL命令（use, show tables, show databases, describe），那麼調用createDdlExecRequest()；
(2)另外一種情況就是Query或者DML命令，那麼就得創建和填充TQueryExecRequest了。
2，根據SQL語法樹生成執行計劃（PlanNode和PlanFragment的生成）
下面就是用Planner把SQL解析出的語法樹轉換成Plan fragments，後者能在各個backend被執行。
Planner planner = new Planner();
ArrayListfragments =
planner.createPlanFragments(analysisResult, request.queryOptions);
這個createPlanFragments()函數是frontend最重要的函數：根據SQL解析的結果和client傳入的query options，生成執行計劃。執行計劃是用PlanFragment的數組表示的，最後會序列化到TQueryExecRequest.fragments然後傳給backend的coordinator去調度執行。
下面進入Planner.createPlanFragments()函數看看執行計劃是怎麼生成的：
首先要搞清楚兩個概念：PlanNode和PlanFragment。
PlanNode是SQL解析出來的邏輯功能節點；PlanFragment是真正的執行計劃節點。
2.1，創建PlanNode
PlanNode singleNodePlan =
createQueryPlan(queryStmt, analyzer, queryOptions.getDefault_order_by_limit());
(1)這個函數首先根據from從句中的第一個TableRef創建一個PlanNode，一般為ScanNode（HdfsScanNode或者HBaseScanNode）。這個ScanNode關聯一個ValueRange的數組（由多個cluster column取值區間組成）表示要讀取的Table的范圍，還關聯一個conjunct（where從句）。
(2)這個SQL語句中TableRef中剩下的其他Table就需要建立HashJoinNode了。進入Planner.createHashJoinNode()函數：首先為這個Table建立ScanNode（同上），然後調用getHashLookupJoinConjuncts()獲取兩表或者多表JOIN的eqJoinConjuncts和eqJoinPredicates，利用這兩個條件創建HashJoinNode。每個HashJoinNode也是樹狀的，會有孩子節點，對於我們舉例的兩表JOIN，孩子節點分別是兩個表對應的ScanNode。（注意目前impala只支持一大一小兩個表的JOIN，默認是左大右小，是通過把右邊的小表分發到每個節點的內存中分別於左邊大表的一個區間進行JOIN過濾實現的。）
(3)如果有group by從句，創建AggregationNode，並把剛才的HashJoinNode設為它的孩子。這里暫時不考慮DISTINCT aggregation function。
(4)如果有order by… limit從句，創建SortNode。
這樣createQueryPlan()函數執行完畢，PlanNode組成的execution tree形成如下：
2.2，創建PlanFragment
接下來就看impala backend節點數目有多少，如果只有一個節點，那麼整棵執行樹都在同一個impalad上執行；否則調用createPlanFragments(singleNodePlan, isPartitioned, false, fragments)把PlanNode組成的執行樹轉換成PlanFragment組成的執行計劃。
下面進入createPlanFragments（）這個函數：
這是一個遞歸函數，沿著PlanNode組成的執行樹遞歸下去，分別創建對應的Fragment。
(1)如果是ScanNode，創建一個PlanFragment（這個PlanFragment的root node是這個ScanNode，而且這個PlanFragment只包含一個PlanNode）。
(2)如果是HashJoinNode，並不是創建一個新的PlanFragment，而是修改leftChildFragment(是一個ScanNode)為以HashJoinNode作為root node的PlanFragment。因為對於HashJoinNode一般有兩個ScanNode孩子，在處理HashJoinNode之前已經把這兩個ScanNode變成了對應的PlanFragment。那麼此時要得到HashJoinNode作為root node的PlanFragment是通過Planner.createHashJoinFragment()函數完成的：首先把當前HashJoinNode作為HashJoinFragment的root node；然後把leftChildFragment中的root PlanNode（也就是參與JOIN的兩個表中左邊的那個表對應的ScanNode）作為HashJoinNode的左孩子；通過調用Planner.connectChildFragment()函數把HashJoinNode的右孩子設置為一個ExchangeNode（這個ExchangeNode表示一個1:n的數據流的receiver）；同時把rightChildFragment（ScanNode作為root node）的destination設置為這個ExchangeNode。
(3)如果是AggregationNode，聚集操作很復雜了。以我們的例子來說明：如果這個AggregationNode不是DISTINCT aggregation的2nd phase（因為本例中的AggregationNode的孩子是HashJoinNode而不是另外一個AggregationNode），首先把剛才生成的HashJoinNode作為root node對應的PlanFragment的root node設置為該AggregationNode，並把原來的root node（即HashJoinNode）設為新root node的孩子。然後通過Planner.createParentFragment()創建一個包含ExchangeNode作為root node的新的PlanFragment。並把孩子PlanFragment的destination設置為這個ExchangeNode。然後在這個新的PlanFragment中創建一個新的AggregationNode作為新的root node並把剛才的ExchangeNode作為其孩子節點。
至此，createPlanFragments（）調用完成，生成的三個PlanFragment如下：
通過createPlanFragments(singleNodePlan, isPartitioned, false, fragments)獲取了所以執行計劃PlanFragment組成的數組fragments，這個數組的最後一個元素就是根節點PlanFragment。然後就是調用PlanFragment.finalize()把這個執行計劃finalize(遞歸finalize每個PlanNode)同時為每個PlanFragment指定 DataStreamSink。
然後回到frontend.createExecRequest()函數中。執行完Planner.createPlanFragments()返回的ArrayList就是完整的執行計劃了。然後就是一次調用PlanFragment.toThrift()把它序列化到TQueryExecRequest。填充TQueryExecRequest的相關變數：dest_fragment_idx，per_node_scan_ranges，query_globals，result_set_metadata等。最後返回TExecRequest型的對象給backend執行。