先决条件

本文假定读者对EVI，DB2 i索引策略，DB2 i星型联接支持和物化查询表（MQT）有基本的了解。 DB2 for i卓越中心团队已经发布了许多提供此背景信息的白皮书。 如有必要，请在“ 参考”部分中查看这些论文的链接。

本文同时包含示例SQL查询和查询的直观说明，以演示如何使用EVI来提高性能。 使用IBM i Navigator随附的Visual Explain工具创建了视觉说明。 有关此工具的更多信息，请参考“参考”部分中包含的数据库查询优化参考。

参考资料部分还包括一个链接，该链接指向DB2 for i卓越中心团队提供SQL性能研讨会的描述。 该研讨会是获得对DB2 for i性能分析和优化概念的深入了解的一流方法。 有关更多详细信息，请参考参考部分中的链接。

本文中描述的功能假定商业智能或分析应用程序是基于DB2 i 7.1构建的，其临时修订级别至少为SF99701第18级。IBM建议客户应用最新的更新以便接收最新的更新。修复和增强。 您可以在“ 参考”部分中找到指向DB2 for i技术更新页面的链接。

总览

在典型的BI或分析环境中，事实表包含一个或多个度量，需要通过对维度进行分组来汇总。 例如，报告可能需要提供按位置维度分组的收入度量的总和。 当事实表包含数百万（或数十亿）行时，一种有效的聚合计算机制对于临时查询的性能至关重要。

EVI并不是DB2 for i的最新成员，而且一直非常适合BI环境中发生的针对大型数据集的临时查询类型。 这些索引基于IBM研究开发的专利技术，于1998年随IBM OS /400®Version 4 Release 3首次使用。EVI的常规使用通过允许数据库管理器有效地实现行的本地选择来提高查询性能。使用跳过顺序处理； 也就是说，将按其物理顺序（而不是随机访问）访问感兴趣的行，并跳过不满足选择条件的行范围。 EVI的另一个常规优点是，统计信息和描述性信息存储在EVI的符号表中，用于每个不同的键，从而使优化器可以在优化查询时使用EVI做出非常明智的选择。 本文讨论了DB2 for i 7.1中的增强功能的好处，该功能允许将度量列的聚合值包含在EVI的符号表中。

在EVI的符号表中包含度量值列的合计值是增强现有索引策略以获得其他性能改进的一种简便方法。 包含意味着EVI的符号表中的每个符号还包括与该符号关联的所有行的一个或多个聚合值。 如果将索引键用作分组标准，则在EVI中包含度量的合计值将为DB2优化器提供用于计算查询中这些值的快速选项。

例如， 图1中显示的表按日期和城市包含收入和利润数字。

图1：按日期和城市划分的收入和利润数字

如果使用城市作为键列创建EVI，则EVI可以包括度量列的有用汇总，例如SUM(revenue)和AVG(profit) 。 创建后，EVI的符号表将如表1所示。

表1：EVI符号表

总和（收入）	AVG（利润）	市
35	14	纽约
150	42	罗切斯特

在城市上分组时，需要计算SUM(revenue)或AVG(profit)的查询只需要访问EVI符号表并检索包括的聚合，而无需访问列表中的（通常很多）行。事实表。

与MQT的比较

许多BI解决方案都使用MQT来存储预聚合的值。 多年来，由于DB2 for i优化器能够利用MQT中预先聚合的数据，因此MQT的使用一直是一项重要的性能技术。 MQT的主要缺点是需要经常刷新它们，并且维护成本可能很高。

作为替代方案，DB2 for i优化器可以使用EVI中包含的预聚合值。 在索引中存储预汇总的值可以立即维护这些值； 结果，无需刷新聚合值以使存储的值与数据保持一致。 总计值的增加不会显着增加索引维护成本。

AVG，COUNT，COUNT_BIG，SUM，STDDEV，STDDEV_SAMP，VARIANCE和VARIANCE_SAMP函数可以作为汇总值表达式包含在EVI中。 EVI的一个限制是，非键列不能包含合计的MIN和MAX值。

在以下情况下，DB2 for i优化器最有可能通过使用EVI中包含的聚合值来优化查询：

• GROUP BY来自单个表
• GROUP BY的引用列在键定义中
• 选择基于索引键
• 承诺控制级别为* NONE或* CHG

这些条件描述了最常见的查询类型，将对其进行优化以利用EVI的符号表中的合计值。 条件不是对合计值何时对优化程序有用的绝对限制。 本文稍后将提供复杂查询的示例，这些示例将进行优化以充分利用所包含的聚合值。

当MQT执行聚合并且GROUP BY引用单个表时，可能可以用包含聚合值的EVI替换MQT。 随着基本表中数据的更改，系统将维护EVI，而MQT则不会。 MQT维护是用户的责任。

对于DB2优化器不太可能使用EVI中包含的聚合值的查询，MQT仍然是一种可能的选择。 当GROUP BY超过一个表时，DB2优化器可以将查询与MQT匹配。 MQT可以与包含MIN或MAX聚合函数的查询匹配。 MQT的另一个功能是，MQT的提交级别必须大于或等于查询的提交级别，但不一定必须是* NONE或* CHG。

何时在EVI中包括合计值

创建包含聚合值而不是包含相同聚合的MQT的EVI可能是有益的。 在允许系统自动维护聚合值的环境中，EVI是有利的。 创建有用的EVI（包括聚合）的一种策略是设计最佳的MQT策略，然后用EVI识别并替换合适的MQT。 如果EVI可能对否则可能使用MQT的查询有用，则该MQT适合用EVI替换。 在单个表上执行聚合的MQT是可能适合替换的MQT的示例。

另一种方法是创建包含汇总值的EVI，作为高级索引策略的一部分。 使用此方法时，如果EVI由于传统原因而对EVI有利，则应该在EVI中包括度量列的汇总，并且经常通过按EVI的键分组来汇总度量列。 然后，优化器将具有可供该组使用的其他聚合信息，可以选择该优化器在查询的实现中使用。 当优化器无法使用所包含的信息进行汇总时，索引仍然可以用于检索准确的统计信息； 此外，（在适当时）EVI可用于表选择，跳过顺序计划或用于索引ANDing和ORing计划。 因此，包括合计值可以在一个查询子集中产生出色的性能（维护成本很低），并且EVI继续被优化器用来对其他查询执行广泛的优化。

通过查看一些示例，将更容易理解包含合计值的效果。

星型模式示例

图2显示了一个非常简单的星型模式，名为sales_bi。 事实表（sales_fact）具有一个度量列（sale_amount_measure）。 事实表提供了用于分组的两个维度。 日期维度（sale_date）和位置（sale_location_id）。 此外，这些维度中的每一个都提供了进一步分组的机会。 例如，sale_date列还允许按年，季度和月分组，而sale_location_id列则允许按城市，州或地区分组（使用sales_location_dimension表）。 如果由于市场营销活动而进行购买的客户这样做，则customer_included_in_marketing列包含“ Y”值。

图2：sales_bi模式

在GROUP BY sale_location_id上优化SUM（）

清单1显示了一个简单的查询，该查询以降序返回按位置ID分组的销售总额。 HAVING子句中的选择条件可确保结果中仅包含位置4、16和13。

清单1：特定位置的sale_amount_measure汇总

SELECT SUM(sale_amount_measure) sum_of_sales,sale_location_id
FROM   sales_fact
GROUP BY sale_location_id
HAVING sale_location_id IN (4, 16, 13)
ORDER BY sum_of_sales DESC

清单1中查询的示例输出如图3所示。

图3：销售总额，按sale_location_id分组

清单1中的查询是一个简单但不常见的示例。 大多数分析查询将涉及与维表的联接。 例如， 清单2中的查询进行联接，以便按状态而不是位置ID对聚合进行分组。 仅包括纽约州，威斯康星州和明尼苏达州。

清单2：按州汇总的sale_amount_measure

SELECT SUM(sale_amount_measure) AS sum_of_sales, state
FROM   sales_fact
INNER JOIN sales_location_dimension
ON (sales_fact.sale_location_id = sales_location_dimension.sale_location_id)
GROUP BY state
HAVING state IN ('NY', 'WI', 'MN')
ORDER BY sum_of_sales
DESC

清单2中查询的输出如图4所示。

图4：按州分组的销售总额

清单1和清单2中的查询都需要访问sales_fact表中的大量行，这将导致性能下降。 因此，通过创建索引来提高这些查询的性能是成功的基础。

回顾了DB2 for i星型连接支持和DB2 for i索引策略（在参考资料部分中找到）的数据库开发人员，可以认识到事实表的sale_location_id列是EVI的关键。 第二个观察结果是，预期EVI的键用作清单1中查询的分组列，而在清单2中 ，状态列的分组基于键列上的层次结构。 由于两个查询都还需要计算SUM(sale_amount_measure) ，因此此聚合是要包含在索引中的不错的选择。

DB2 for i Index Advisor不建议在EVI中包含合计值。 但是，由于出于常规原因通常需要在EVI中包含合计值，因此可以使用Index Advisor来帮助标识必须创建的索引。 在确定了预期的EVI之后，可以检查导致推荐该EVI的查询，以确定EVI中是否应包含合计值。 （查看导致建议创建索引的语句的功能是针对DB2 i 7.1的一项技术更新。有关更多详细信息，请参阅“ 参考”部分中的链接。）

DB2 for i优化器可以确定是否在查询中使用EVI的聚合值。 包含这些值的额外维护成本很小，不是主要的考虑因素。

使用包含的汇总值创建EVI

创建一个EVI并包含一个或多个聚合值很简单。 CREATE ENCODED VECTOR INDEX语句具有INCLUDE子句，可用于指定非键集合值。 清单3显示了编码矢量索引SQL语法，该索引将sale_location_id列定义为键，并包括SUM（sale_amount_measure）作为其他非键数据。

清单3：创建一个EVI语句

CREATE ENCODED VECTOR INDEX sales_fact_location_id_evi
ON sales_fact(sale_location_id ASC)
INCLUDE(SUM(sale_amount_measure))

另外，对IBM i Navigator进行了增强，以便新的索引对话框包含一个用于添加非关键聚合值的选项， 如图5所示。

图5：带有其他非关键数据的选项选项卡

本示例仅包含索引的单个汇总值。 实际上，创建索引时通常会包含多个汇总值。 不必为每个需要包括的汇总度量创建单独的EVI。

EVI的使用包括合计值

在索引之后清单3被创建，在示出的查询中的视觉解释清单1中示出了图6中 。

图6：直观说明显示了一个EVI符号表探针

仅需要访问EVI的符号表，而无需访问事实表。 之所以SUM(sale_amount_measure)是因为符号表现在具有为sale_location_id列的每个不同值维护的SUM(sale_amount_measure)结果。

通常，当查询涉及单个表时，查询优化器最能应用此技术，因为联接是在聚合之前进行评估的。 但是，如果我们看一下清单2的直观说明（如图7所示），我们会看到优化器有时能够重写查询，以使联接与EVI的符号表一起使用。 重写允许使用EVI中包含的合计值。 无需探测或扫描事实表，就可以将符号表中针对位置ID的部分聚合进一步聚合为状态分组的值。

图7：可视化说明显示了与EVI的符号表的联接

在EVI的符号表中包括汇总度量是整体索引策略的一部分。 警报读者可以看出， 图7显示了一个表格扫描，该表格从sales_location_dimension表中选择具有特定状态值的行。 由于表中只有很少的行符合选择标准，因此表扫描不是最佳的。 作为改进，DB2 for i优化器建议在state列上创建一个二进制基数。 创建建议的二进制基数索引之后， 清单 8中的查询的直观说明如图8所示。

图8：创建建议的二进制基数索引后的直观说明

通过GROUP BY ROLLUP优化SUM（）

下一个示例演示了OLAP查询的一种常见类型，其中对从sales_fact表中的sale_date维度派生的年，季度和月值执行GROUP BY ROLLUP。

清单4显示了一个查询，其中按年，季度和月汇总了总销售额。

清单4：GROUP BY ROLLUP（年，季度，月）

SELECT SUM(sale_amount_measure)        AS sum_of_sales,YEAR(sale_date)                 AS sale_year, QUARTER(sale_date)              AS sale_quarter, MONTH(sale_date)                AS sale_month
FROM sales_fact
GROUP BY ROLLUP(YEAR(sale_date), QUARTER(sale_date), MONTH(sale_date))
ORDER BY YEAR(sale_date), QUARTER(sale_date), MONTH(sale_date)

清单4中查询的一些示例结果（部分）如图9所示。

图9：GROUP BY ROLLUP的结果集（年，季度，月）

在其他临时查询中，年，季度和月值可能会用于本地选择。 这使这些表达式成为EVI的绝佳候选键。

索引顾问不建议将派生的表达式作为EVI的可能键，因此，数据库设计者识别类似于此情形的能力很重要。 派生密钥上的EVI会对性能产生重大影响。

由于预期的EVI的键列也用于对SUM(sale_amount_measure)聚合值进行分组，因此可以为导出的键表达式创建单个EVI，并包括聚合值。

使用派生键和包含值创建EVI

清单5显示了CREATE INDEX语句SQL语句。 这将表达式指定为键，并包括其他非键聚合值。

清单5：创建年，季度和月的编码矢量索引

CREATE ENCODED VECTOR INDEX sales_fact_date_yqm_evi
ON sales_bi.sales_fact (YEAR(sale_date), QUARTER(sale_date),MONTH(sale_date) )
INCLUDE(SUM(sale_amount_measure))

EVI在GROUP BY ROLLUP中的使用

清单4中查询的直观说明如图10所示。 该查询不再需要访问事实表，因为执行GROUP BY ROLLUP所需的所有信息现在都在EVI中。

图10：使用EVI的符号表对GROUP BY ROLLUP的直观说明

与GROUP BY ROLLUP相似，当分组涉及GROUP BY CUBE或GROUP BY GROUPING SETS时，DB2 for i优化器可以使用EVI的符号表。

作为DB2 for i 7.1技术更新（PTF组SF99701级别18）的一部分，添加了优化器使用GROUP BY ROLLUP，GROUP BY CUBE或GROUP BY GROUPING SETS中包含的EVI聚合的功能。 参考部分中包含指向这些功能的技术更新说明的链接。

在行的子集上优化AVG（）

在BI应用程序中，通常要求使用独立于分组条件的选择条件对事实表中的行的子集执行聚合。 例如，业务分析师可能希望对sales_fact表中的sale_amount_measure列执行汇总（使用一个或多个维度进行分组），但仅对customer_included_in_marketing列中值为“ Y”的行进行汇总。

清单6显示了一个示例查询，该查询仅针对那些由于营销活动而进行购买的销售计算按州和星期几分组的平均sale_amount_measure值。 仅包括纽约州，威斯康星州和明尼苏达州。

清单6：包含事件的州和星期几的平均sale_amount_measure

SELECTCAST(AVG(sale_amount_measure) AS DECIMAL(5,2)) average_sale, state, DAYOFWEEK_ISO(sale_date) day_of_week
FROM sales_fact
INNER JOIN sales_location_dimension
ON (sales_fact.sale_location_id =sales_location_dimension.sale_location_id)
WHERE customer_included_in_marketing = 'Y'
GROUP BY state, DAYOFWEEK_ISO(sale_date)
HAVING state IN ('NY', 'WI', 'MN')
ORDER BY average_sale DESC

清单6中查询的示例输出如图11所示。

图11：平均销售结果集

创建EVI以使分组列和选择列都是索引的键，这是一种允许利用包含的聚合的方法。 清单7中显示了此方法的示例create index语句。

清单7：使用分组和选择列作为键创建EVI

CREATE ENCODED VECTOR INDEX sales_fact_location_day_marketing_evi
ON sales_fact (sale_location_id, DAYOFWEEK_ISO(sale_date),customer_included_in_marketing)
INCLUDE (AVG(sale_amount_measure))

清单7中所示方法的问题在于，EVI的符号表中的条目（和合计值）的数量可能不必要地变大。 符号表包含EVI键列中值的每个组合的汇总值。 如果在选择涉及多个列且每个列具有许多可能值的情况下采用此方法，则EVI的符号表可能会增长到索引的有用性大大降低的大小。 另外，用于选择的列并不总是具有有限范围的不同值，这使该列成为EVI键的不切实际的选择。

创建稀疏的EVI

对于清单6中的查询，创建一个仅包含customer_included_in_marketing值为'Y'的行的稀疏EVI是合适的解决方案。 通常，必须谨慎使用此方法。 仅当查询的选择条件与用于创建索引的选择条件完全匹配时，稀疏索引才对优化程序有用。 清单8显示了用于创建稀疏EVISQL语法。

清单8：创建一个包含汇总值的稀疏EVI

CREATE ENCODED VECTOR INDEX
sales_fact_location_day_select_marketing_y_evi ON sales_fact ( sale_location_id,DAYOFWEEK_ISO(sale_date) )
WHERE customer_included_in_marketing = 'Y'
INCLUDE (AVG(sale_amount_measure))

稀疏EVI用于聚合的用法

图12显示了清单8中创建稀疏EVI之后的清单6中查询的直观说明。 稀疏EVI的符号表包含与查询的WHERE子句匹配的行的平均值（在位置ID上）。 结果，无需访问事实表即可实现查询。

图12：使用稀疏EVI的查询的直观说明

当包含的值无用时的索引用法

不能总是使用EVI中包含的聚合值来实现查询。 清单9显示了一个示例查询，其中包含的聚集值无济于事。 该查询包含与清单4中的查询类似的GROUP BY ROLLUP子句，但是该聚合仅包含具有sale_date为2011或2012年的行和一个值为'EAST'的区域。

清单9：无法从包含的聚合中受益的查询

SELECT SUM(sale_amount_measure) AS sum_of_sales,YEAR(sale_date)          AS sale_year, QUARTER(sale_date)       AS sale_quarter, MONTH(sale_date)         AS sale_month
FROM sales_fact
INNER JOIN sales_location_dimension ON (sales_fact.sale_location_id =sales_location_dimension.sale_location_id)
WHERE YEAR(sale_date) IN (2011, 2012) AND region = 'EAST'
GROUP BY ROLLUP(YEAR(sale_date), QUARTER(sale_date), MONTH(sale_date))
ORDER BY YEAR(sale_date),QUARTER(sale_date), MONTH(sale_date)

清单9的示例输出如图13所示。

图13：2011年和2012年东部地区的销售额，按年，季度和月汇总

清单9中所示的查询是一个普通的临时BI查询的示例，其中将不使用索引中包含的合计值，因为选择和分组标准不仅限于具有以下特征的任何单个EVI的符号表中的信息：被创建。 但是， 清单3和清单5中创建的EVI对于查询仍然具有重要的整体价值。

图14显示了清单9中查询的直观说明。 尽管不会使用EVI包含的聚合值来执行聚合，但是清单3和清单5中的EVI可以用于在事实表中生成满足选择谓词的相对记录号（RRN）行列表。 RRN列表允许查询仅访问具有有趣行的页面，这可以大大提高查询的性能。 因为维护包含的聚合值对索引维护成本的影响很小，所以包括可用于其他查询的其他信息的该附加信息仍对应用程序有利。

图14：无法使用包含的聚合值的查询的直观说明

摘要

在EVI的符号表中包括聚合值的功能是DB2 i 7.1中的一项强大功能，可以帮助提高BI或分析应用程序的性能。 本文介绍了几个示例，其中在聚合的矢量索引中包括聚合值是有益的。 创建包含聚合的索引是一个好主意，因为维护聚合值的维护成本极低，并且性能提升非常可观。

要了解和最大化DB2 for i SQL的所有功能，需要学习，培训和经验； 结果是出色的投资回报。 系统和技术小组实验室服务i2卓越中心的DB2团队提供了许多出色的教育机会，其中包括梦幻般的 DB2 for i SQL性能研讨会。 “ 参考”部分包括指向研讨会网站的链接，以及指向IBM Lab Services and Training网站的链接。

致谢

特别感谢Systems and Technology Group Lab Services for i2卓越中心和DB2 for i优化器团队对本文的审阅和评论。

翻译自: https://www.ibm.com/developerworks/ibmi/library/i-accelerated-analytics-db2-evi-tech/index.html