以下的文章主要介紹的是IBM DB2數據庫SQL編碼優化的基礎教程，這種特定查詢的重要性即為，查詢越重要，您可能就越應該通過創建索引來對其進行調優。如果您正在編碼 CIO 要每天都運行的查詢，那麼您應該確保它提供最佳性能。
因此，為該特定查詢構建索引是很重要的。反之，職員的查詢也許就沒有必要看得那麼重，所以也許應該利用現有索引來執行查詢。當然，決定取決於應用程序對業務的重要性 - 而不只是用戶的重要性。
索引設計涉及的內容比到目前為止我所討論的要多得多。例如，您也許要考慮索引重載以實現僅索引訪問(index-only access)。如果 SQL 查詢要尋找的所有數據都包含在索引中，那麼 DB2 也許只使用索引就可以滿足該請求。請考慮我們前面的 SQL 語句。給定了關於 EMPNO 和 DEPTNO 的信息，我們要尋找 LASTNAME 和 SALARY。
我們還從創建關於 EMPNO 和 DEPTNO 列的索引開始。如果我們在索引中還包含了 LASTNAME 和 SALARY，我們就不再需要訪問 EMP 表，因為我們需要的所有數據都已經在索引中。該技術可以大大提高性能，因為它減少了 I/O 請求的數量。
請記住：使每個查詢成為僅索引訪問是不謹慎，甚至也是不可能的。您應該謹慎使用該技術以便用於特別棘手或重要的 SQL 語句。
SQL 編碼准則
當您編寫訪問 DB2 數據的 SQL 語句時，要確保遵循以下三個編碼 SQL 的准則以獲得最佳性能。當然，SQL 性能是一個復雜的話題，而且了解 SQL 的執行方式的每一個細微差別可能要花一生的時間。但是，這些簡單的規則可以使您進入開發高性能 DB2 應用程序的正軌。
第一條規則是始終在每條 SQL SELECT 語句的 SELECT 列表中只提供 確實需要檢索的那些列 。另一種說法就是“不要使用 SELECT *”。簡寫 SELECT * 表示您要檢索正在被訪問的表中的所有列。這適用於“快捷但不恰當的方式獲得的“(quick and dirty)查詢，但卻是應用程序的壞實踐，因為：
DB2 表在將來可能需要更改，以包括附加列。SELECT * 也會檢索那些新的列，而如果沒有進行費時的更改，您的程序也許無法處理附加的數據。
DB2 將為被請求返回的每一列消耗附加資源。如果程序不需要數據，它就不會尋找它。即使程序需要每一列，最好根據 SQL 語句中的名稱來顯式地尋找每一列，以便增加清晰度和避免以前犯的錯誤。
不要尋找您已經知道的東西 。這聽起來似乎顯而易見，但大多數程序員都曾經違反過這條規則。舉一個典型的示例，考慮以下 SQL 語句有什麼錯誤：
- SELECT EMPNO, LASTNAME, SALARY
- FROM EMP
- WHERE EMPNO = ’000010’;
放棄嗎?問題是 EMPNO 已經包含在 SELECT 列表中。您已經知道了 EMPNO 將等於值“000010”，因為那就是 WHERE 子句要 DB2 做的事。但在 WHERE 子句中列出了 EMPNO，DB2 還會盡職地檢索該列。這會產生附加開銷，從而降低性能。
在 SQL 中 使用 WHERE 子句過濾數據 ，而不是在程序中到處使用它進行過濾。這也是新手容易犯的錯誤。在 DB2 將數據返回到程序之前，最好由 DB2 過濾數據。這是因為 DB2 使用附加 I/O 和 CPU 資源來獲取每一行數據。傳遞到程序的行越少，SQL 的效率就越高：
- SELECT EMPNO, LASTNAME, SALARY
- FROM EMP
- WHERE SALARY > 50000.00;
與只讀取所有數據而不使用 WHERE 子句，然後在程序中檢查 SALARY 是否大於 50000.00 的做法相比，該 SQL 更好。
使用參數化查詢 。參數化 SQL 語句包含了變量，也稱作參數(或參數標記)。典型的參數化查詢使用這些參數來代替文字值，因此 WHERE 子句條件可以在運行時更改。通常程序被設計成最終用戶可以在運行查詢之前提供參數的值。這允許使用一個查詢根據提供給參數的不同的值返回不同的結果。
參數化查詢的主要性能好處是優化器可以制定在重復執行語句時能夠再使用的存取路徑。與每次 WHERE 子句中需要一個新值就發出一條全新的 SQL 語句相比，這可以給程序增加很大的性能收益。
但是，這些規則並不是 SQL 性能調優的最終和最高目標 - 決不是。您可能需要附加的、深入的調優。但遵循前面的規則將確保您不會犯降低應用程序性能的“新手”錯誤。
特定IBM DB2數據庫應用程序開發技巧
無論您使用的是 Delphi、C++Builder 還是 Kylix，某些技巧和准則將幫助您確保在訪問 DB2 數據時獲得好的性能。例如，在某些情況下，使用 dbExpress TM來代替 ODBC/JDBC 或 ADO 可以提高查詢性能。dbExpress 是用於從 Delphi(或 Borland Kylix™)處理動態 SQL 的跨平台接口。
要確保在您的應用程序中經常發出 COMMIT 語句。COMMIT 語句控制工作單元。發出 COMMIT 會將自上一個 COMMIT 語句之後的所有工作“永遠”記錄到IBM DB2數據庫中。在發出 COMMIT 之前，可以使用 ROLLBACK 語句回滾工作。
當修改數據(使用 INSERT、UPDATE 和 DELETE)但沒有發出 COMMIT 時，DB2 將在數據上加一把鎖並保持該鎖 - 這把鎖會使其它應用程序在等待檢索被鎖住的數據時超時。通過在工作完成時發出 COMMIT 語句，並且確保數據是正確的，就釋放了該數據以供其它應用程序使用。
另外，構建應用程序時要考慮使用情況。例如，當某個特定查詢返回幾千行給最終用戶時，要慎重處理。對於在程序和最終用戶之間的在線交互，很少會用到幾百行以上的數據。您可以在 SQL 語句上使用 FETCH FIRST nROWS ONLY 子句來限制返回到查詢的數據量。例如，考慮以下查詢：
- SELECT EMPNO, LASTNAME, SALARY
- FROM EMP
- WHERE SALARY > 10000.00
- FETCH FIRST 200 ROWS ONLY;
該查詢將只返回 200 行。如果有超過 200 行符合條件也沒有關系;如果您嘗試從查詢中 FETCH(訪存)超過 200 行，DB2 將用 +100 SQLCODE 表明數據結束。當您想要限制返回給程序的數據量時，這種方法很有用。
DB2 支持另一個名為 OPTIMIZE FOR nROWS 的子句，該子句不限制要返回給游標的行數，但從性能角度看可能是有幫助的。使用 OPTIMIZE FOR nROWS 子句告訴 DB2 如何處理 SQL 語句。例如：
- SELECT EMPNO, LASTNAME, SALARY
- FROM EMP
- WHERE SALARY > 10000.00
- OPTIMIZE FOR 20 ROWS;
這告訴 DB2 嘗試盡快訪存前 20 行。如果您的 Delphi 應用程序在顯示從IBM DB2數據庫檢索出來的數據行時每次顯示 20 行，那麼這將非常有用。
對於只讀游標，使用 FOR READ ONLY 子句確保游標無歧義。Delphi 不能在 DB2 游標中執行位置更新，因此將 FOR READ ONLY 附加到每條 SELECT 語句後面可以使游標成為無歧義的只讀游標，從而對 DB2 有所幫助。例如：
- SELECT EMPNO, LASTNAME, SALARY
- FROM EMP
- WHERE SALARY > 10000.00
- FOR READ ONLY;
結束語
了解 SQL 編碼以獲得最佳性能的基礎知識將使您的 Delphi 企業應用程序的性能立即得到增長。但我只揭露了冰山一角。您需要學習日益增多的 SQL 的復雜類型，包括連接、子選擇和聯合等。您還需要學習如何最好地編寫這些 SQL 語句以及如何發現 DB2 選擇的存取路徑來滿足您的 SQL 請求。確實，還有許多要學習。但是您已經學習了一些如何最大限度地利用 DB2 SQL 的初步知識，盡情地享用這些知識吧。
