在大多數(shù)情況下，一套應用系統(tǒng)的效率問題在表象上都指向了I/O問題。I/O效率低下的確是可能的原因之一，但除了存儲設備在硬件、操作系統(tǒng)方面的約束原因之外，應用系統(tǒng)數(shù)據(jù)庫設計及數(shù)據(jù)庫操作的SQL語句也可能是產(chǎn)生I/O瓶頸問題的根本性原因。試想如果我們想從北京到天津，但我們偏偏要從鄭州繞一圈過去，這時候開什么車已經(jīng)不重要了，因為這時路遠是主要矛盾。

因此，在應用系統(tǒng)開發(fā)之初，SQL程序員除了要了解業(yè)務需求以外，還必須關注應用中SQL的效率可用性。SQL的效率可用性在開發(fā)中往往可以反映為如下幾個技術層面的運用：

?恰當?shù)臄?shù)據(jù)庫連接機制。

?高效的游標使用和管理。

?SQL執(zhí)行中的硬解析、軟解析。

?無論哪種解析，其計劃是優(yōu)化的。

如下圖所示：

Oracle中的客戶連接和SQL執(zhí)行

Oracle客戶連接是以進程方式體現(xiàn)在操作系統(tǒng)中的，而在Oracle中則表現(xiàn)為一個個的服務器進程。每個服務器進程都有其獨立的堆棧結(jié)構(gòu)、會話數(shù)據(jù)信息、游標信息、數(shù)據(jù)排序區(qū)域。不僅如此，所有的服務器進程會共享Oracle SGA，在SQL執(zhí)行過程中，所有的SQL會在SGA中的Library Cache（庫緩存）內(nèi)存結(jié)構(gòu)中被緩存，同時被緩存的還有該SQL對應的可執(zhí)行偽代碼（Executing Plan：具體的執(zhí)行計劃）。

客戶連接本身就是一個資源消耗型工作，從應用開發(fā)的角度來講，數(shù)據(jù)庫同時連接的用戶數(shù)應盡可能地少，這樣才會降低服務器的壓力。同時，對于某

個具體的用戶連接進程來說，其數(shù)據(jù)庫連接最好在應用啟動時完成，而不是在應用進行中不斷地連接、斷開、再連接。推而廣之，在一套多層結(jié)構(gòu)的應用里，中間件層（應用服務器層）提供的“數(shù)據(jù)庫連接池”（connection pool功能）就是用于實現(xiàn)這個目的的，它可保證不會出現(xiàn)頻繁的數(shù)據(jù)庫連接及斷開操作。

所以，中間件服務器的數(shù)據(jù)庫連接緩存池可以起到連接緩沖的作用，這是一種在互聯(lián)網(wǎng)下避免數(shù)據(jù)庫連接沖擊載荷的重要技術手段。

站在SQL的角度，最大限度地減少SQL執(zhí)行過程中的語法分析活動，是SQL優(yōu)化的一個準則。我們知道，在Oracle執(zhí)行SQL語句時，語法分析是解釋并執(zhí)行SQL語句的首要過程，包括分析SQL句法、檢查執(zhí)行權(quán)限、生成執(zhí)行計劃、裝載共享結(jié)構(gòu)等。語法分析結(jié)束后，數(shù)據(jù)庫優(yōu)化器將確定其執(zhí)行計劃，并將其編譯成偽代碼后提交Oracle內(nèi)核執(zhí)行。語法分析有兩種不同類型的分析方式和操作步驟：硬解析和軟解析。

如果數(shù)據(jù)庫內(nèi)核系統(tǒng)發(fā)現(xiàn)一個SQL語句是首次被提交，沒有在共享池中找到該SQL的執(zhí)行痕跡，則數(shù)據(jù)庫不得不對這條語句執(zhí)行硬解析，包括SQL語法分析、確定執(zhí)行計劃、編譯執(zhí)行等過程。這種解析方式必然會造成對資源的大量使用。

軟解析與硬解析不同。如果一個SQL語句被提交給數(shù)據(jù)庫，而這條語句（SQL及其對應的SQL執(zhí)行計劃Execution Plan）可以在一個稱為庫緩存（Library Cache）的共享池中找到，那這條SQL語句可能就不必再次硬解析了，原因是不久以前（若干時間內(nèi)，可能是幾分鐘或幾小時內(nèi)）某個用戶曾經(jīng)執(zhí)行過這條SQL語句。如果這條SQL語句已被緩存到庫緩存中（共享），其語法分析和編譯結(jié)果可以被后續(xù)的用戶所使用，從而避免再次被解析。

顯然，這有益于降低系統(tǒng)資源的使用，提高整體性能。有一點需要說明，雖然這種情況下的硬解析過程省略了，但SQL的句法分析和用戶執(zhí)行權(quán)限檢查仍然存在，因此，軟解析仍然會部分消耗系統(tǒng)資源。這是SQL執(zhí)行的必然代價。

從性能上看，一條SQL在經(jīng)歷硬解析后，如果再次被執(zhí)行，則執(zhí)行應為軟解析方式。這就要求SQL在編程中具有一致性。因此，在設計過程中最好能夠制定某種編程規(guī)范。我曾在北京的一家著名數(shù)據(jù)處理公司看到過其內(nèi)部編制的SQL規(guī)范，摘取其中幾條供大家參考，如下所示：

對于表名的使用

規(guī)則一：必須大寫

規(guī)則二：多表連接查詢，表名按升序自然排列，不能含有多余的空格

規(guī)則三：優(yōu)先使用預定義視圖，而非在線視圖（inline view）或子查詢

規(guī)則四：使用在線視圖（inline view）或子查詢時，請先行提交需求

……

對于列名的使用

規(guī)則一：必須小寫

規(guī)則二：列的出現(xiàn)順序嚴格按照其在表中的位置按順序出現(xiàn)，不能含有多余空格

……

SQL語句所使用的變量

規(guī)則一：使用綁定變量

規(guī)則二：變量的數(shù)據(jù)類型定義需采用%type

……

SQL模塊化的要求

規(guī)則一：基礎模塊建議在存儲過程、函數(shù)中完成

規(guī)則二：基礎模塊群建議在包中完成

SQL語句的注釋說明

……

在這些規(guī)范中，可看到有關規(guī)范化的兩個舉措：

?SQL的規(guī)范化編寫

?SQL的可重用性側(cè)重

程序員可通過編寫盡量標準且通用的SQL語句，來適應這種硬解析及軟解析執(zhí)行機制，避免系統(tǒng)中出現(xiàn)大量“陌生”的SQL語句，進而減少對CPU資源的申請（次數(shù)和時間），這不也是優(yōu)化的一部分嗎？

為了保證絕大多數(shù)SQL語句可以在共享池中共享，程序代碼中的SQL應盡可能使用綁定變量，這樣可以避免SQL在執(zhí)行中因變量的不同，而導致數(shù)據(jù)庫優(yōu)化器對SQL語義曲解，進而導致硬解析出現(xiàn)。

當然，綁定變量的使用也是典型的雙刃劍，但大多數(shù)情況下其效果是好的。不過有一點要提醒的是，在程序設計階段就進行約定非常重要。SQL編程規(guī)范要爭取在設計階段完成。

文章引用：http://www.duhuilife.cn/new/131.html

本站文章為深圳網(wǎng)站建設·源美網(wǎng)絡原創(chuàng)策劃，如有版權(quán)糾紛或者違規(guī)問題，請聯(lián)系我們刪除，謝謝！