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. 修改查询内容
