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