對於數據庫管理員而言，數據庫應用程序的性能是一項最為重要的因素。顯著縮短決策支持查詢響應時間的一種方法是使用物化查詢表 (MQT)。
在本期文章中，我將討論 MQT 的概念並演示如何創建和填充系統維護和用戶維護的 MQT。我還將分析一些能從 MQT 中受益的場景。
什麼是 MQT ？
MQT 的定義依查詢結果而定。可以認為 MQT 是一種物化視圖，因為 MQT 的數據來自一個或多個基本表。其差異在於如何生成和存儲 MQT 數據。通常，視圖的數據是每次在引用視圖時通過對其所依托的主體執行查詢而生成的；數據位於視圖所引用的底層基本表中。MQT 數據是定期（由您控制）或在指定時間點通過對 MQT 所依托的主體執行查詢而生成的；數據位於 MQT 內部。與任何其他表相類似，MQT 可以有索引，並且 RUNSTATS 實用工具可以用於生成和存儲關於 MQT 的統計數據。
MQT 提供了一種強大的方式來改善復雜查詢的響應速度，特別是執行以下一個或多個操作的查詢：
在一個或多個維度度上聚合數據
結合或聚合一組表
執行重復計算
執行資源密集型掃描
訪問數據的公共子集 —— 也就是說，從 “熱” 垂直或水平數據庫分區檢索數據
在分區的數據庫環境中從表或表的一部分檢索數據
MQT 的知識已緊密集成到 IBM DB2 SQL 和 XQuery 編譯器中。在此查詢重寫階段，DB2 優化器將匹配查詢與已有 MQT 並確定是否為訪問基本表的查詢替換 MQT。（如果使用 MQT，則 Explain 工具可以提供關於所選 MQT 的信息）。基本表越大，響應速度的潛在改善空間就越大，因為 MQT 的增長速度將慢於它的底層基本表。
創建 MQT
創建 MQT 所采用的方法是執行特殊格式的 CREATE TABLE SQL 語句：
其中：
TableName標識將分配給所創建 MQT 的名稱
SELECTStatement標識用於填充所創建 MQT 的 SQL 查詢
可以創建兩種不同類型的 MQT：系統維護 MQT 和用戶維護 MQT。不能對系統維護 MQT 執行插入、更新和刪除操作。但是，當對 MQT 所依托的所有底層表執行更改時，REFRESH IMMEDIATE 系統維護 MQT 會自動更新。REFRESH 關鍵字允許您控制如何維護 MQT 中的數據：REFRESH IMMEDIATE 指示對底層表的更改將級聯到 MQT，而 REFRESH DEFERRED 表示僅當執行 REFRESH TABLE 語句時才會刷新 MQT 中的數據。
用戶維護的 MQT 允許執行插入、更新或刪除操作，並且可以使用導入或加載操作對其進行填充。但是，不能通過執行 REFRESH TABLE 語句來填充它們，也不能使用所指定的 REFRESH IMMEDIATE 選項來創建它們。從本質上說，用戶定義的 MQT 是一個需要由 DBA 填充的概要表，但 DB2 優化器可用於改善查詢性能。（如果不希望 DB2 優化器使用 MQT，只需通過用於創建 MQT 的 CREATE TABLE 語句指定 DISABLE QUERY OPTIMIZATION 選項）。
何時創建 MQT
應該如何確定 MQT 是否能提供價值？或者應該創建什麼樣的 MQT ？ IBM DB2 Design Advisor 可以為您解答這些問題。使用您所提供的最新的數據庫統計數據、DB2 優化器、快照監控信息和 / 或具體的查詢或一組 SQL 語句（稱作工作負載），Design Advisor 可以就為您推薦可改善性能的索引、MQT 或集群（MDC）表。索引、MQT 或 MDC 表；從中獲取的統計信息；以及創建它們所需的 Data Definition Language (DDL) 語句都可以寫入到用戶創建的 ADVISE_INDEX 表中。
MQT 和子域
雖然可以為所使用的每個查詢謂語定義 MQT（順便提一下，這並不是一個好主意），但決策支持和數據倉庫環境通常包含一組常用的、非常小的、反復執行的查詢子謂語和限定符。一種強大但通常被忽略的 MQT 用法是優化對解析此類子謂語的常用的數據子域的訪問。
在此場景中，MQT 未包含匯總數據，而是用於幫助 DB2 優化器迅速識別和分離符合條件的行；MQT 用於在一些比較復雜的查詢中對行執行預先限定。舉例來說，報表系統可以有多個使用 YESTERDAY 數據子域的報表。一個報表可以關注昨天的總體銷售，另一個報表可以根據區域來關注昨天的銷售，而第三個報表可以根據產品來關注昨天的銷售。這三個查詢可能共享常用謂語 WHERE DATE = YESTERDAY，它用於立即限制記錄集。
如果您創建了三個單獨的 MQT 來回答這些查詢，則它們需要維護大量磁盤空間。但如果只是創建了一個 MQT 來界定域，比如說 YESTERDAY；則包含在其中的屬性不可能會發生改變，比如說 “Region” 和 “Product_ID”；然後對這個 MQT 創建一個適當的索引，關於 YESTERDAY 的所有查詢都可以由這個 MQT 來滿足。JOIN 和行提取操作是最有可能需要的，但這些操作所使用的數據子集要小很多。
此處的想法很簡單：讓 DB2 盡可能方便快捷地縮減多個查詢中所涉及的數據的大小，而不需要讀取多個索引，同時避免創建多個類似的 MQT 以及後續的管理工作。查找查詢中的公共模型，考慮它們所表達的域，並確定哪些屬性最常用，哪些屬性最有可能減小數據大小。然後，為所執行的查詢創建一個適當的 MQT，對基本表和 MQT 創建適當的索引，並及時更新統計數據。最後，讓 DB2 優化器選擇使用基本表還是 MQT；不要在 SQL 中明確引用 MQT。
