DB2數據庫和ORACLE數據庫一樣，DB2數據庫里面也是通過優化器來分析你的SQL，生成它認為***的執行計劃(Access Plan)。DB2的優化器實際上是一個標準規則集合，一般來說我們只要告訴DB2要檢索什么，而不是如何檢索。

那么DB2的優化器是根據什么來判斷SQL的***存取路徑呢?

DB2的優化器是基于成本的優化器，也就是CBO(Cost Based Optmizer)。也就是說DB2 優化器會應用查詢成本公式，該公式對每條可能的存取路徑的四個因素進行評估和權衡:CPU 成本、I/O 成本、DB2 系統目錄中的統計信息和實際的 SQL 語句。

那么我們來簡單看一下DB2的優化器的工作流程:

1. DB2的優化器，在接收到SQL語句后，會首先校驗SQL的語法，確保是正確的SQL

2. 根據當前的系統環境信息，生成***的執行計劃來優化SQL語句

3. 把SQL翻譯成計算機指令語言，并執行這個優化后的SQL

4. 返回結果，或者存儲它們，以便將來的執行

在我們看來，DB2 系統目錄中統計信息是讓DB2優化器正確工作的一個非常重要的依據。這些統計信息向優化器提供了與正在被優化的 SQL 語句將要訪問的表狀態相關的信息。這些信息主要包括:

Table--包括表的記錄數、PAGE、PCTFREE以及COMPRESS等信息，相關的系統視圖是:sysstat.tables、syscat.tables

Columns—包括COLUMNS的數量、長度、分布特征以及COMPRESS等信息,相關的系統視圖是:sysstat.columns、syscat. columns

Index--包括是否存在索引、索引的組織(葉子頁的數量和級別的數量)、索引鍵的離散值的數量以及是否群集索引, 相關的系統視圖是:sysstat.indexes、syscat. indexes

其他的還有分區/節點組信息和表空間的信息

如何及時更新這些信息呢?保證DB2優化器正確的工作，在DB2里面提供了以下的辦法。

RUNSTATS與REOGCHK

Runstats這個命令的功能主要就是收集數據庫對象的狀態信息，這對數據庫使用合理的ACCESS PLAN是至關重要的。一般來說，以下幾種情況下面，我們需要用runstats來收集統計信息:

1. 在給表創建一個index后，我們***做一次runstat。這個情況也是大家經常忽略的。很多時候大家在給表增加了一個index后，分析執行計劃，發現沒有變化，覺得很奇怪。其實這個時候，你需要做一次runstats，就可以了。在8.2里面，DB2做了很好的改進，可以避免這個問題，在創建index的時候，可以立即更新你的信息。

2. 在對table做了一次reorg后，記得要做一次runstats。因為對表做reorg，會修改表的很多信息，比如高水位等，所以做一次runstats,可以更新統計信息。

3. 當你的表里面的數據發生了比較大的變化，一般來說，大約表里面的數據量的10%-20%發生了變化，就應該作一次runstats。這些變化包括刪除，修改，插入。對于一些非常大的表，比方在數據倉庫的項目里面，某些事實表非常巨大。這個時候，完整的對一個大表作runstats可能花費時間相當大，DB2 8.1里面支持我們對這些大表作抽樣，比方說只對20%的數據作runstats，這樣的話，一般來說也能保證得到正確的執行計劃。當然首先要確保這個表里面的數據***分布比較均勻。

大家通過上文的學習有什么收獲嗎？相信大家現在對DB2中更新執行計劃的操作有了大體的了解，以后在工作中遇到類似問題就能夠輕松解決，希望上文中涉及到的內容對大家能夠有所幫助。