V7R1M0 為 DB2 for i SQL 查詢引擎 (SQE) 添加了自適應查詢處理 (AQP) 功能 “自適應”表示查詢計劃有可能實時變化（在當前查詢運行過程中），也有可能隨著時間的推移而發生變化（在未來運行查詢時）。AQP 框架允許使用 SQE 監視器，了解 IBM i 上各查詢的運
v7r1m0 為 db2 for i sql 查詢引擎 (sqe) 添加了自適應查詢處理 (aqp) 功能 “自適應”表示查詢計劃有可能實時變化（在當前查詢運行過程中），也有可能隨著時間的推移而發生變化（在未來運行查詢時）。aqp 框架允許使用 sqe 監視器，了解 ibm i 上各查詢的運行時特征并作出反應。因此，ibm i 用戶即可獲得又一層性能保護，防止發生緩慢查詢。
查詢優化綜述
圖 1 展示了 SQE 引擎的架構。圖中展示了一個從用戶傳遞到 SQE 的查詢，SQL 分析器會處理它，隨后將分析后的查詢傳遞給查詢優化器。考慮查詢訪問計劃的多種組合之后，優化器將選擇在時間和 / 或系統資源（CPU、RAM 和 I/O 等）方面成本最低廉的查詢計劃。
每個訪問計劃會考慮包括各種表的連接順序以及每個表的訪問方法（索引、表掃描、散列表和排序等）。根據需要處理的行數，每種訪問方法都有不同的性能特征。因此，查詢優化器會多次查詢統計信息管理器，以了解查詢不同部分將會選擇的行數，如 圖 1 所示。
圖 1. SQE 引擎的架構
在確定最終查詢計劃之后，會將查詢訪問計劃傳遞給引擎，以便執行查詢計劃，向用戶返回恰當的結果集，如圖中所示。最后，會將這個查詢訪問計劃保存到訪問計劃緩存之中，如果再次運行相同的查詢，就可以重用計劃緩存中的計劃，避免優化器重新優化查詢并獲得更快的查詢性能。
連接排序示例
為了優化查詢性能，最重要的標準就是獲得正確的連接排序。最終，優化的目標是重寫查詢，盡可能及早丟棄不屬于結果集的行，并且不會將資源浪費在以后會被拒絕的行上。下面的示例會闡明這一點。為了讓本示例更簡潔一些，示例中將忽略索引、并行處理和其他 DB2 優化策略。
考慮 圖 2 給出的示例中的 SQL。如果將 Orders 連接到 Customers，則必須掃描 Orders 中從 1 到 100,000 的行，對于符合“Back Ordered”標準的每一行，都要探測 Customers 中的 custID，查找與標準相匹配的姓名。假設選擇了 Orders 中 25% 的行（其 STATUS = ‘Back Ordered’），則需要對 Customers 探測 25,000 次（100,000 的 25%）。因此，從理論上來講，我們要執行 125,000（100,000 + 25,000）次行查找。
圖 2. 將 Orders 連接到 Customers
接下來，如果使用 DB2 for i 中稱為 Look-ahead Predicate Generation (LPG) 的技術，可以減輕連接排序帶來的影響。以圖 3 為例。在這個示例中，我們仍然從 Orders 連接到 Customers，但在修改查詢內容，在選擇標準中添加關注的客戶 ID。因此，SQE 首先掃描 Customers（1000 行），在 custID 中查找關注的 NAME (o.custid=1)。隨后，它使用該項標準修改查詢（如 圖 3 所示），掃描 Orders（100,000 行），對于匹配整個 WHERE 子句的行，可連接回 Customers。在這個 LPG 場景中，將會檢查 10101 (1000 + 10000 +1) 行。我們在這里可以看到，僅僅在這個小示例中，LPG 就將 Orders 到 Customers 連接的性能提高了 25%。請注意，在使用 LPG 處理更加復雜的查詢時，往往能實現更加顯著的性能改進。
圖 3. 修改查詢內容
