当前位置:Gxlcms > mysql > DB2fori自适应查询处理简介

DB2fori自适应查询处理简介

时间:2021-07-01 10:21:17 帮助过:48人阅读

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 引擎的架构
图 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
图 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. 修改查询内容
图 3. 修改查询内容

人气教程排行