先決條件

本文假定讀者對(duì)EVI，DB2 i索引策略，DB2 i星型聯(lián)接支持和物化查詢表（MQT）有基本的了解。 DB2 for i卓越中心團(tuán)隊(duì)已經(jīng)發(fā)布了許多提供此背景信息的白皮書。 如有必要，請(qǐng)?jiān)凇?參考”部分中查看這些論文的鏈接。

本文同時(shí)包含示例SQL查詢和查詢的直觀說明，以演示如何使用EVI來提高性能。 使用IBM i Navigator隨附的Visual Explain工具創(chuàng)建了視覺說明。 有關(guān)此工具的更多信息，請(qǐng)參考“參考”部分中包含的數(shù)據(jù)庫(kù)查詢優(yōu)化參考。

參考資料部分還包括一個(gè)鏈接，該鏈接指向DB2 for i卓越中心團(tuán)隊(duì)提供SQL性能研討會(huì)的描述。 該研討會(huì)是獲得對(duì)DB2 for i性能分析和優(yōu)化概念的深入了解的一流方法。 有關(guān)更多詳細(xì)信息，請(qǐng)參考參考部分中的鏈接。

本文中描述的功能假定商業(yè)智能或分析應(yīng)用程序是基于DB2 i 7.1構(gòu)建的，其臨時(shí)修訂級(jí)別至少為SF99701第18級(jí)。IBM建議客戶應(yīng)用最新的更新以便接收最新的更新。修復(fù)和增強(qiáng)。 您可以在“ 參考”部分中找到指向DB2 for i技術(shù)更新頁(yè)面的鏈接。

總覽

在典型的BI或分析環(huán)境中，事實(shí)表包含一個(gè)或多個(gè)度量，需要通過對(duì)維度進(jìn)行分組來匯總。 例如，報(bào)告可能需要提供按位置維度分組的收入度量的總和。 當(dāng)事實(shí)表包含數(shù)百萬（或數(shù)十億）行時(shí)，一種有效的聚合計(jì)算機(jī)制對(duì)于臨時(shí)查詢的性能至關(guān)重要。

EVI并不是DB2 for i的最新成員，而且一直非常適合BI環(huán)境中發(fā)生的針對(duì)大型數(shù)據(jù)集的臨時(shí)查詢類型。 這些索引基于IBM研究開發(fā)的專利技術(shù)，于1998年隨IBM OS /400?Version 4 Release 3首次使用。EVI的常規(guī)使用通過允許數(shù)據(jù)庫(kù)管理器有效地實(shí)現(xiàn)行的本地選擇來提高查詢性能。使用跳過順序處理； 也就是說，將按其物理順序（而不是隨機(jī)訪問）訪問感興趣的行，并跳過不滿足選擇條件的行范圍。 EVI的另一個(gè)常規(guī)優(yōu)點(diǎn)是，統(tǒng)計(jì)信息和描述性信息存儲(chǔ)在EVI的符號(hào)表中，用于每個(gè)不同的鍵，從而使優(yōu)化器可以在優(yōu)化查詢時(shí)使用EVI做出非常明智的選擇。 本文討論了DB2 for i 7.1中的增強(qiáng)功能的好處，該功能允許將度量列的聚合值包含在EVI的符號(hào)表中。

在EVI的符號(hào)表中包含度量值列的合計(jì)值是增強(qiáng)現(xiàn)有索引策略以獲得其他性能改進(jìn)的一種簡(jiǎn)便方法。 包含意味著EVI的符號(hào)表中的每個(gè)符號(hào)還包括與該符號(hào)關(guān)聯(lián)的所有行的一個(gè)或多個(gè)聚合值。 如果將索引鍵用作分組標(biāo)準(zhǔn)，則在EVI中包含度量的合計(jì)值將為DB2優(yōu)化器提供用于計(jì)算查詢中這些值的快速選項(xiàng)。

例如， 圖1中顯示的表按日期和城市包含收入和利潤(rùn)數(shù)字。

圖1：按日期和城市劃分的收入和利潤(rùn)數(shù)字

如果使用城市作為鍵列創(chuàng)建EVI，則EVI可以包括度量列的有用匯總，例如SUM(revenue)和AVG(profit) 。 創(chuàng)建后，EVI的符號(hào)表將如表1所示。

表1：EVI符號(hào)表

總和（收入） AVG（利潤(rùn)） 市

35	14	紐約
150	42	羅切斯特

在城市上分組時(shí)，需要計(jì)算SUM(revenue)或AVG(profit)的查詢只需要訪問EVI符號(hào)表并檢索包括的聚合，而無需訪問列表中的（通常很多）行。事實(shí)表。

與MQT的比較

許多BI解決方案都使用MQT來存儲(chǔ)預(yù)聚合的值。 多年來，由于DB2 for i優(yōu)化器能夠利用MQT中預(yù)先聚合的數(shù)據(jù)，因此MQT的使用一直是一項(xiàng)重要的性能技術(shù)。 MQT的主要缺點(diǎn)是需要經(jīng)常刷新它們，并且維護(hù)成本可能很高。

作為替代方案，DB2 for i優(yōu)化器可以使用EVI中包含的預(yù)聚合值。 在索引中存儲(chǔ)預(yù)匯總的值可以立即維護(hù)這些值； 結(jié)果，無需刷新聚合值以使存儲(chǔ)的值與數(shù)據(jù)保持一致。 總計(jì)值的增加不會(huì)顯著增加索引維護(hù)成本。

AVG，COUNT，COUNT_BIG，SUM，STDDEV，STDDEV_SAMP，VARIANCE和VARIANCE_SAMP函數(shù)可以作為匯總值表達(dá)式包含在EVI中。 EVI的一個(gè)限制是，非鍵列不能包含合計(jì)的MIN和MAX值。

在以下情況下，DB2 for i優(yōu)化器最有可能通過使用EVI中包含的聚合值來優(yōu)化查詢：

• GROUP BY來自單個(gè)表
• GROUP BY的引用列在鍵定義中
• 選擇基于索引鍵
• 承諾控制級(jí)別為* NONE或* CHG

這些條件描述了最常見的查詢類型，將對(duì)其進(jìn)行優(yōu)化以利用EVI的符號(hào)表中的合計(jì)值。 條件不是對(duì)合計(jì)值何時(shí)對(duì)優(yōu)化程序有用的絕對(duì)限制。 本文稍后將提供復(fù)雜查詢的示例，這些示例將進(jìn)行優(yōu)化以充分利用所包含的聚合值。

當(dāng)MQT執(zhí)行聚合并且GROUP BY引用單個(gè)表時(shí)，可能可以用包含聚合值的EVI替換MQT。 隨著基本表中數(shù)據(jù)的更改，系統(tǒng)將維護(hù)EVI，而MQT則不會(huì)。 MQT維護(hù)是用戶的責(zé)任。

對(duì)于DB2優(yōu)化器不太可能使用EVI中包含的聚合值的查詢，MQT仍然是一種可能的選擇。 當(dāng)GROUP BY超過一個(gè)表時(shí)，DB2優(yōu)化器可以將查詢與MQT匹配。 MQT可以與包含MIN或MAX聚合函數(shù)的查詢匹配。 MQT的另一個(gè)功能是，MQT的提交級(jí)別必須大于或等于查詢的提交級(jí)別，但不一定必須是* NONE或* CHG。

何時(shí)在EVI中包括合計(jì)值

創(chuàng)建包含聚合值而不是包含相同聚合的MQT的EVI可能是有益的。 在允許系統(tǒng)自動(dòng)維護(hù)聚合值的環(huán)境中，EVI是有利的。 創(chuàng)建有用的EVI（包括聚合）的一種策略是設(shè)計(jì)最佳的MQT策略，然后用EVI識(shí)別并替換合適的MQT。 如果EVI可能對(duì)否則可能使用MQT的查詢有用，則該MQT適合用EVI替換。 在單個(gè)表上執(zhí)行聚合的MQT是可能適合替換的MQT的示例。

另一種方法是創(chuàng)建包含匯總值的EVI，作為高級(jí)索引策略的一部分。 使用此方法時(shí)，如果EVI由于傳統(tǒng)原因而對(duì)EVI有利，則應(yīng)該在EVI中包括度量列的匯總，并且經(jīng)常通過按EVI的鍵分組來匯總度量列。 然后，優(yōu)化器將具有可供該組使用的其他聚合信息，可以選擇該優(yōu)化器在查詢的實(shí)現(xiàn)中使用。 當(dāng)優(yōu)化器無法使用所包含的信息進(jìn)行匯總時(shí)，索引仍然可以用于檢索準(zhǔn)確的統(tǒng)計(jì)信息； 此外，（在適當(dāng)時(shí)）EVI可用于表選擇，跳過順序計(jì)劃或用于索引ANDing和ORing計(jì)劃。 因此，包括合計(jì)值可以在一個(gè)查詢子集中產(chǎn)生出色的性能（維護(hù)成本很低），并且EVI繼續(xù)被優(yōu)化器用來對(duì)其他查詢執(zhí)行廣泛的優(yōu)化。

通過查看一些示例，將更容易理解包含合計(jì)值的效果。

星型模式示例

圖2顯示了一個(gè)非常簡(jiǎn)單的星型模式，名為sales_bi。 事實(shí)表（sales_fact）具有一個(gè)度量列（sale_amount_measure）。 事實(shí)表提供了用于分組的兩個(gè)維度。 日期維度（sale_date）和位置（sale_location_id）。 此外，這些維度中的每一個(gè)都提供了進(jìn)一步分組的機(jī)會(huì)。 例如，sale_date列還允許按年，季度和月分組，而sale_location_id列則允許按城市，州或地區(qū)分組（使用sales_location_dimension表）。 如果由于市場(chǎng)營(yíng)銷活動(dòng)而進(jìn)行購(gòu)買的客戶這樣做，則customer_included_in_marketing列包含“ Y”值。

圖2：sales_bi模式

在GROUP BY sale_location_id上優(yōu)化SUM（）

清單1顯示了一個(gè)簡(jiǎn)單的查詢，該查詢以降序返回按位置ID分組的銷售總額。 HAVING子句中的選擇條件可確保結(jié)果中僅包含位置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中的查詢是一個(gè)簡(jiǎn)單但不常見的示例。 大多數(shù)分析查詢將涉及與維表的聯(lián)接。 例如， 清單2中的查詢進(jìn)行聯(lián)接，以便按狀態(tài)而不是位置ID對(duì)聚合進(jìn)行分組。 僅包括紐約州，威斯康星州和明尼蘇達(dá)州。

清單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表中的大量行，這將導(dǎo)致性能下降。 因此，通過創(chuàng)建索引來提高這些查詢的性能是成功的基礎(chǔ)。

回顧了DB2 for i星型連接支持和DB2 for i索引策略（在參考資料部分中找到）的數(shù)據(jù)庫(kù)開發(fā)人員，可以認(rèn)識(shí)到事實(shí)表的sale_location_id列是EVI的關(guān)鍵。 第二個(gè)觀察結(jié)果是，預(yù)期EVI的鍵用作清單1中查詢的分組列，而在清單2中 ，狀態(tài)列的分組基于鍵列上的層次結(jié)構(gòu)。 由于兩個(gè)查詢都還需要計(jì)算SUM(sale_amount_measure) ，因此此聚合是要包含在索引中的不錯(cuò)的選擇。

DB2 for i Index Advisor不建議在EVI中包含合計(jì)值。 但是，由于出于常規(guī)原因通常需要在EVI中包含合計(jì)值，因此可以使用Index Advisor來幫助標(biāo)識(shí)必須創(chuàng)建的索引。 在確定了預(yù)期的EVI之后，可以檢查導(dǎo)致推薦該EVI的查詢，以確定EVI中是否應(yīng)包含合計(jì)值。 （查看導(dǎo)致建議創(chuàng)建索引的語句的功能是針對(duì)DB2 i 7.1的一項(xiàng)技術(shù)更新。有關(guān)更多詳細(xì)信息，請(qǐng)參閱“ 參考”部分中的鏈接。）

DB2 for i優(yōu)化器可以確定是否在查詢中使用EVI的聚合值。 包含這些值的額外維護(hù)成本很小，不是主要的考慮因素。

使用包含的匯總值創(chuàng)建EVI

創(chuàng)建一個(gè)EVI并包含一個(gè)或多個(gè)聚合值很簡(jiǎn)單。 CREATE ENCODED VECTOR INDEX語句具有INCLUDE子句，可用于指定非鍵集合值。 清單3顯示了編碼矢量索引SQL語法，該索引將sale_location_id列定義為鍵，并包括SUM（sale_amount_measure）作為其他非鍵數(shù)據(jù)。

清單3：創(chuàng)建一個(gè)EVI語句

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

另外，對(duì)IBM i Navigator進(jìn)行了增強(qiáng)，以便新的索引對(duì)話框包含一個(gè)用于添加非關(guān)鍵聚合值的選項(xiàng)， 如圖5所示。

圖5：帶有其他非關(guān)鍵數(shù)據(jù)的選項(xiàng)選項(xiàng)卡

本示例僅包含索引的單個(gè)匯總值。 實(shí)際上，創(chuàng)建索引時(shí)通常會(huì)包含多個(gè)匯總值。 不必為每個(gè)需要包括的匯總度量創(chuàng)建單獨(dú)的EVI。

EVI的使用包括合計(jì)值

在索引之后清單3被創(chuàng)建，在示出的查詢中的視覺解釋清單1中示出了圖6中 。

圖6：直觀說明顯示了一個(gè)EVI符號(hào)表探針

僅需要訪問EVI的符號(hào)表，而無需訪問事實(shí)表。 之所以SUM(sale_amount_measure)是因?yàn)榉?hào)表現(xiàn)在具有為sale_location_id列的每個(gè)不同值維護(hù)的SUM(sale_amount_measure)結(jié)果。

通常，當(dāng)查詢涉及單個(gè)表時(shí)，查詢優(yōu)化器最能應(yīng)用此技術(shù)，因?yàn)槁?lián)接是在聚合之前進(jìn)行評(píng)估的。 但是，如果我們看一下清單2的直觀說明（如圖7所示），我們會(huì)看到優(yōu)化器有時(shí)能夠重寫查詢，以使聯(lián)接與EVI的符號(hào)表一起使用。 重寫允許使用EVI中包含的合計(jì)值。 無需探測(cè)或掃描事實(shí)表，就可以將符號(hào)表中針對(duì)位置ID的部分聚合進(jìn)一步聚合為狀態(tài)分組的值。

圖7：可視化說明顯示了與EVI的符號(hào)表的聯(lián)接

在EVI的符號(hào)表中包括匯總度量是整體索引策略的一部分。 警報(bào)讀者可以看出， 圖7顯示了一個(gè)表格掃描，該表格從sales_location_dimension表中選擇具有特定狀態(tài)值的行。 由于表中只有很少的行符合選擇標(biāo)準(zhǔn)，因此表掃描不是最佳的。 作為改進(jìn)，DB2 for i優(yōu)化器建議在state列上創(chuàng)建一個(gè)二進(jìn)制基數(shù)。 創(chuàng)建建議的二進(jìn)制基數(shù)索引之后， 清單 8中的查詢的直觀說明如圖8所示。

圖8：創(chuàng)建建議的二進(jìn)制基數(shù)索引后的直觀說明

通過GROUP BY ROLLUP優(yōu)化SUM（）

下一個(gè)示例演示了OLAP查詢的一種常見類型，其中對(duì)從sales_fact表中的sale_date維度派生的年，季度和月值執(zhí)行GROUP BY ROLLUP。

清單4顯示了一個(gè)查詢，其中按年，季度和月匯總了總銷售額。

清單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中查詢的一些示例結(jié)果（部分）如圖9所示。

圖9：GROUP BY ROLLUP的結(jié)果集（年，季度，月）

在其他臨時(shí)查詢中，年，季度和月值可能會(huì)用于本地選擇。 這使這些表達(dá)式成為EVI的絕佳候選鍵。

索引顧問不建議將派生的表達(dá)式作為EVI的可能鍵，因此，數(shù)據(jù)庫(kù)設(shè)計(jì)者識(shí)別類似于此情形的能力很重要。 派生密鑰上的EVI會(huì)對(duì)性能產(chǎn)生重大影響。

由于預(yù)期的EVI的鍵列也用于對(duì)SUM(sale_amount_measure)聚合值進(jìn)行分組，因此可以為導(dǎo)出的鍵表達(dá)式創(chuàng)建單個(gè)EVI，并包括聚合值。

使用派生鍵和包含值創(chuàng)建EVI

清單5顯示了CREATE INDEX語句SQL語句。 這將表達(dá)式指定為鍵，并包括其他非鍵聚合值。

清單5：創(chuàng)建年，季度和月的編碼矢量索引

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所示。 該查詢不再需要訪問事實(shí)表，因?yàn)閳?zhí)行GROUP BY ROLLUP所需的所有信息現(xiàn)在都在EVI中。

圖10：使用EVI的符號(hào)表對(duì)GROUP BY ROLLUP的直觀說明

與GROUP BY ROLLUP相似，當(dāng)分組涉及GROUP BY CUBE或GROUP BY GROUPING SETS時(shí)，DB2 for i優(yōu)化器可以使用EVI的符號(hào)表。

作為DB2 for i 7.1技術(shù)更新（PTF組SF99701級(jí)別18）的一部分，添加了優(yōu)化器使用GROUP BY ROLLUP，GROUP BY CUBE或GROUP BY GROUPING SETS中包含的EVI聚合的功能。 參考部分中包含指向這些功能的技術(shù)更新說明的鏈接。

在行的子集上優(yōu)化AVG（）

在BI應(yīng)用程序中，通常要求使用獨(dú)立于分組條件的選擇條件對(duì)事實(shí)表中的行的子集執(zhí)行聚合。 例如，業(yè)務(wù)分析師可能希望對(duì)sales_fact表中的sale_amount_measure列執(zhí)行匯總（使用一個(gè)或多個(gè)維度進(jìn)行分組），但僅對(duì)customer_included_in_marketing列中值為“ Y”的行進(jìn)行匯總。

清單6顯示了一個(gè)示例查詢，該查詢僅針對(duì)那些由于營(yíng)銷活動(dòng)而進(jìn)行購(gòu)買的銷售計(jì)算按州和星期幾分組的平均sale_amount_measure值。 僅包括紐約州，威斯康星州和明尼蘇達(dá)州。

清單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：平均銷售結(jié)果集

創(chuàng)建EVI以使分組列和選擇列都是索引的鍵，這是一種允許利用包含的聚合的方法。 清單7中顯示了此方法的示例create index語句。

清單7：使用分組和選擇列作為鍵創(chuàng)建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的符號(hào)表中的條目（和合計(jì)值）的數(shù)量可能不必要地變大。 符號(hào)表包含EVI鍵列中值的每個(gè)組合的匯總值。 如果在選擇涉及多個(gè)列且每個(gè)列具有許多可能值的情況下采用此方法，則EVI的符號(hào)表可能會(huì)增長(zhǎng)到索引的有用性大大降低的大小。 另外，用于選擇的列并不總是具有有限范圍的不同值，這使該列成為EVI鍵的不切實(shí)際的選擇。

創(chuàng)建稀疏的EVI

對(duì)于清單6中的查詢，創(chuàng)建一個(gè)僅包含customer_included_in_marketing值為'Y'的行的稀疏EVI是合適的解決方案。 通常，必須謹(jǐn)慎使用此方法。 僅當(dāng)查詢的選擇條件與用于創(chuàng)建索引的選擇條件完全匹配時(shí)，稀疏索引才對(duì)優(yōu)化程序有用。 清單8顯示了用于創(chuàng)建稀疏EVISQL語法。

清單8：創(chuàng)建一個(gè)包含匯總值的稀疏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中創(chuàng)建稀疏EVI之后的清單6中查詢的直觀說明。 稀疏EVI的符號(hào)表包含與查詢的WHERE子句匹配的行的平均值（在位置ID上）。 結(jié)果，無需訪問事實(shí)表即可實(shí)現(xiàn)查詢。

圖12：使用稀疏EVI的查詢的直觀說明

當(dāng)包含的值無用時(shí)的索引用法

不能總是使用EVI中包含的聚合值來實(shí)現(xiàn)查詢。 清單9顯示了一個(gè)示例查詢，其中包含的聚集值無濟(jì)于事。 該查詢包含與清單4中的查詢類似的GROUP BY ROLLUP子句，但是該聚合僅包含具有sale_date為2011或2012年的行和一個(gè)值為'EAST'的區(qū)域。

清單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年?yáng)|部地區(qū)的銷售額，按年，季度和月匯總

清單9中所示的查詢是一個(gè)普通的臨時(shí)BI查詢的示例，其中將不使用索引中包含的合計(jì)值，因?yàn)檫x擇和分組標(biāo)準(zhǔn)不僅限于具有以下特征的任何單個(gè)EVI的符號(hào)表中的信息：被創(chuàng)建。 但是， 清單3和清單5中創(chuàng)建的EVI對(duì)于查詢?nèi)匀痪哂兄匾恼w價(jià)值。

圖14顯示了清單9中查詢的直觀說明。 盡管不會(huì)使用EVI包含的聚合值來執(zhí)行聚合，但是清單3和清單5中的EVI可以用于在事實(shí)表中生成滿足選擇謂詞的相對(duì)記錄號(hào)（RRN）行列表。 RRN列表允許查詢僅訪問具有有趣行的頁(yè)面，這可以大大提高查詢的性能。 因?yàn)榫S護(hù)包含的聚合值對(duì)索引維護(hù)成本的影響很小，所以包括可用于其他查詢的其他信息的該附加信息仍對(duì)應(yīng)用程序有利。

圖14：無法使用包含的聚合值的查詢的直觀說明

摘要

在EVI的符號(hào)表中包括聚合值的功能是DB2 i 7.1中的一項(xiàng)強(qiáng)大功能，可以幫助提高BI或分析應(yīng)用程序的性能。 本文介紹了幾個(gè)示例，其中在聚合的矢量索引中包括聚合值是有益的。 創(chuàng)建包含聚合的索引是一個(gè)好主意，因?yàn)榫S護(hù)聚合值的維護(hù)成本極低，并且性能提升非?？捎^。

要了解和最大化DB2 for i SQL的所有功能，需要學(xué)習(xí)，培訓(xùn)和經(jīng)驗(yàn)； 結(jié)果是出色的投資回報(bào)。 系統(tǒng)和技術(shù)小組實(shí)驗(yàn)室服務(wù)i2卓越中心的DB2團(tuán)隊(duì)提供了許多出色的教育機(jī)會(huì)，其中包括夢(mèng)幻般的 DB2 for i SQL性能研討會(huì)。 “ 參考”部分包括指向研討會(huì)網(wǎng)站的鏈接，以及指向IBM Lab Services and Training網(wǎng)站的鏈接。

致謝

特別感謝Systems and Technology Group Lab Services for i2卓越中心和DB2 for i優(yōu)化器團(tuán)隊(duì)對(duì)本文的審閱和評(píng)論。

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

總結(jié)

以上是生活随笔為你收集整理的1叉叉加速器分析_加速分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。