《報(bào)表性能優(yōu)化》PPT課件

ABAP：SAP報(bào)表的性能優(yōu)化,1、關(guān)于表連接語(yǔ)句（INNERJOIN,LEFTJOIN.）寫報(bào)表的時(shí)候，表與表之間的關(guān)聯(lián)是不可避免的。通常而言，表連接語(yǔ)句要掌握的原則有：(1)將最有效的查詢條件所對(duì)應(yīng)的表放在第一位。換言之，讓查詢第一個(gè)表后所得到的結(jié)果集就盡可能小。比如有一張報(bào)表叫做訂單狀態(tài)統(tǒng)計(jì)表，可能查完VBAK、VBAP后還查詢LIPS、VTTP等，界面上的查詢條件很多。不過據(jù)了解得知，該報(bào)表主要是查看昨天創(chuàng)建或前幾天創(chuàng)建的訂單。那么最有效的限制條件自然是訂單創(chuàng)建日期，以及銷售組織了，而表連接的主表宜選用VBAK。(2)確定了表連接的次序后，應(yīng)考慮將查詢條件盡量限制在靠前的表里。比如選擇屏幕上有個(gè)物料號(hào)的查詢條件，而我們知道訂單VBAP和交貨單LIPS均有物料號(hào)，那就應(yīng)該視情況而定，如果表連接中VBAP更早出現(xiàn)，那么WHERE子句中就使用vbapmatnrINs_matnr，反之就是lipsmatnrINs_matnr。(3)兩個(gè)表之間進(jìn)行連接的時(shí)候，應(yīng)考慮關(guān)鍵字段或索引字段的作用。比如查詢VTTP和LIPS時(shí)，關(guān)聯(lián)關(guān)系是vttpvbeln=lipsvbeln。那么vttp在前，lips在后，就會(huì)比較快，因?yàn)楦鶕?jù)vttp的vbeln查詢lips時(shí)，vbeln是lips的關(guān)鍵字段，速度較快。而反過來如果lips在前，那根據(jù)lipsvbeln查詢vttp會(huì)慢一些，除非vbeln是vttp的索引字段。,2，先構(gòu)建RANGE再執(zhí)行SQL語(yǔ)句有時(shí)我們所能用的查詢條件不是很理想，比如查詢LIKP卻必須用公司代碼，而非銷售組織。此時(shí)普通做法是用LIKP與TVKO根據(jù)VKORG進(jìn)行表聯(lián)接，從而限制TVKOBUKRS的值。還有一種有效的辦法是，通過TVKO查詢到當(dāng)期公司代碼所對(duì)應(yīng)的全部銷售組織，從而組建一個(gè)RANGE出來，再根據(jù)此RANGE查詢LIKP。當(dāng)然要注意RANGE的行項(xiàng)目有上限的，在ECC6中大概2萬行將導(dǎo)致ABAPDUMP。提示：DATAr_vkorgTYPERANGEOFlikp-vkorg.SIGN=I,OPTION=EQ,LOW=XXXX即可往r_vkorg中放入多個(gè)單值。,3，F(xiàn)orAllEntries與SelectSingle的比較就個(gè)人而言，筆者不是很喜歡ForAllEntries語(yǔ)句，因?yàn)樗娜秉c(diǎn)多于優(yōu)點(diǎn)。很多人都會(huì)說，為什么呀，F(xiàn)orAllEntries不是比SelectSingle快么？事實(shí)到底怎樣呢，讓我們做個(gè)比較。假設(shè)我們有個(gè)內(nèi)表代表銷售訂單的行項(xiàng)目，該內(nèi)表有10萬行。此時(shí)我們要根據(jù)LIPS的VGBEL和VGPOS，查詢這些訂單行項(xiàng)目對(duì)應(yīng)的交貨單行項(xiàng)目。,ENDLOOP.對(duì)于SELECTSINGLE而言，由于LIPS有個(gè)VGB的SAP自帶索引，每次查詢都挺快，即便循環(huán)10萬次，速度雖然快不了但也沒什么大的危害。對(duì)于ForAllEntries的第一步，的確比SELECTSINGLE快些，本來10萬次的SELECTSINGLE，變成了1萬次的查詢（如果BASIS設(shè)置了參數(shù)為10），每次查詢10個(gè)訂單行項(xiàng)目。但是第二步就很慢了，暫估it_lips為8萬行，則對(duì)于it_vbap的10萬個(gè)行項(xiàng)目，有8萬個(gè)行項(xiàng)目執(zhí)行READTABLE語(yǔ)句平均需要4萬次才能搜索到it_lips的目標(biāo)行，另有2萬個(gè)行項(xiàng)目將讀遍it_lips然后才發(fā)現(xiàn)沒有對(duì)應(yīng)的目標(biāo)行。所以我們一共需要搜索48億次，太慢了！在此針對(duì)ForAllEntries的使用提出幾點(diǎn)意見：（1）如果是根據(jù)某數(shù)據(jù)量大的內(nèi)表用ForAllEntries讀取數(shù)據(jù)量小的配置表，比如TVAK/T006等，那不如把ForAllEntries直接去掉，把表里的幾十條數(shù)據(jù)全部取出。,（2）使用ForAllEntries時(shí)，SELECT語(yǔ)句后面的字段必須包含所查表關(guān)鍵字段。比如上面的vbeln/posnr就是lips的關(guān)鍵字段。如果不含關(guān)鍵字段，比如SELECTlfimgFROMlipsForAllEntries*，那么當(dāng)LIPS中兩個(gè)條目關(guān)鍵字段不同而lfimg相同時(shí)，會(huì)被SAP自動(dòng)過濾掉一條。（3）上面關(guān)于性能問題，應(yīng)該利用BINARYSEARCH、SORTEDTABLE或者HASHEDTABLE來解決。詳見下面第四節(jié)。4，關(guān)于BINARYSEARCH/SORTEDTABLE/HASHEDTABLE的使用BINARYSEARCH即二分法查找，在保證內(nèi)表按查詢字段以升序排列的時(shí)候，可以采用二分法查找。二分法查找的速度很快，最大查詢次數(shù)為log2n。以上面的例子來說，如果it_lips事先按vgbel和vgpos排好序，則每次查找最多不超過17次。則對(duì)于it_vbap的10萬個(gè)行項(xiàng)目，僅100多萬次就可以搞定了！當(dāng)使用READTABLE語(yǔ)法時(shí)，如果查詢字段跟SORTEDTABLE的排序開始字段能匹配上，則SAP將自動(dòng)采用二分法查找。比如it_lips是SORTEDTABLE且以vgbel和vgpos排序，則當(dāng)readtable以vgbel進(jìn)行查找時(shí)，系統(tǒng)會(huì)自動(dòng)采用二分法。但如果readtable以vgpos和其他字段進(jìn)行查找，由于vgpos并非SORTEDTABLE的第一排序字段，系統(tǒng)將采用直線查找，速度會(huì)慢很多?？傊琒ORTEDTABLE的排序字段次序也很關(guān)鍵。,針對(duì)STANDARDTABLE排序后可以進(jìn)行二分法查找，使用SORTEDTABLE也可進(jìn)行二分法查找，那么二者有什么區(qū)別呢？簡(jiǎn)單來說，由于SORTEDTABLE自始至終都保持排序，如果需要對(duì)內(nèi)部進(jìn)行頻繁的插入、刪除操作，則不推薦使用SORTEDTABLE，性能會(huì)很差。而另一方面，如果我們要用的是類似LOOPATit_lipsWHEREvgbel=*的語(yǔ)法（而非READTABLE）時(shí)，對(duì)于STANDARDTABLE就無法采用二分法查找，或者說會(huì)很麻煩。而對(duì)于SORTEDTABLE，系統(tǒng)會(huì)自動(dòng)采用二分法優(yōu)化查找過程。至于HASHEDTABLE，筆者用得也不太多。查看SAP的標(biāo)準(zhǔn)代碼，貌似用得也沒很多。理論上HASHEDTABLE可以比SORTEDTABLE更快些，但需要耗用更大的存儲(chǔ)空間。當(dāng)某程序采用了二分法查找之后，如果效果還不是很理想，建議可以用HASHEDTABLE試試。,5，將循環(huán)內(nèi)的重復(fù)性工作進(jìn)行緩沖有時(shí)我們的內(nèi)表數(shù)據(jù)量很大，但又不得不在每次循環(huán)的時(shí)候，都進(jìn)行類似的一些操作，比如調(diào)用函數(shù)FI_PERIOD_DETERMINE獲取某日期對(duì)應(yīng)的會(huì)計(jì)年度和期間，調(diào)用函數(shù)MD_CONVERT_MATERIAL_UNIT進(jìn)行單位轉(zhuǎn)換，等等。每個(gè)函數(shù)的調(diào)用背后都要執(zhí)行一系列的讀表以及運(yùn)算工作，程序的效率明顯下降了。所以我們得想出有效的辦法。比如針對(duì)FI_PERIOD_DETERMINE的調(diào)用，可以改用循環(huán)前對(duì)函數(shù)G_PERIODS_OF_YEAR_GET的調(diào)用。根據(jù)公司代碼BUKRS讀取T001-PERIV，然后調(diào)用G_PERIODS_OF_YEAR_GET獲取某會(huì)計(jì)年度每個(gè)會(huì)計(jì)期間對(duì)應(yīng)的起始日期和結(jié)束日期。這樣在循環(huán)內(nèi)部，只要根據(jù)上面的結(jié)果即可算出某日期對(duì)應(yīng)的會(huì)計(jì)年度和期間了。又比如針對(duì)MD_CONVERT_MATERIAL_UNIT的調(diào)用。相信對(duì)于it_vbap的10萬個(gè)行項(xiàng)目，物料號(hào)重復(fù)的有很多。所以可以先匯總物料號(hào)，然后一次性讀取表MARM以存儲(chǔ)換算關(guān)系。有了MARM的換算關(guān)系，循環(huán)中大量的單位換算就可以自己算了，如果無法換算的再考慮調(diào)用函數(shù)MD_CONVERT_MATERIAL_UNIT。（函數(shù)MD_CONVERT_MATERIAL_UNIT除了讀取MARM的換算關(guān)系，還會(huì)考慮同一維度單位間的換算關(guān)系比如G和KG的關(guān)系，所以其功能更強(qiáng)大。）,6，關(guān)于字段的增強(qiáng)以及TABLEINDEX的創(chuàng)建這里提到字段的增強(qiáng)，主要是性能方面相關(guān)的。假設(shè)我們需要基于系統(tǒng)所有的billingdocument做個(gè)動(dòng)作，比如將其導(dǎo)出到金稅系統(tǒng)。至少有兩種方案：第一是新建一個(gè)表，專門記錄已經(jīng)導(dǎo)出到金稅的開票憑證；第二是在系統(tǒng)標(biāo)準(zhǔn)的開票憑證抬頭表vbrk中新增一個(gè)字段，記錄是否已導(dǎo)出到金稅。用戶在處理業(yè)務(wù)的時(shí)候肯定會(huì)反復(fù)查詢“未導(dǎo)出到金稅”的所有開票憑證。那么第一種方案下，我們需要先查詢VBRK表（比如得到1萬條記錄），然后針對(duì)自建表的記錄（比如得到9800條記錄）做個(gè)減法，最后得到200條記錄的結(jié)果集。而第二種方案就快多了，查詢VBRK的時(shí)候判斷新字段=“未導(dǎo)出”即可。隨著業(yè)務(wù)的持續(xù)，VBRK表的條目將越來越多，而“未導(dǎo)出”的條目則會(huì)維持在一個(gè)較為平穩(wěn)的數(shù)字上，為了有效區(qū)分歷史數(shù)據(jù)和現(xiàn)用數(shù)據(jù)，可添加TABLEINDEX，提高報(bào)表的查詢速度。很多SAP標(biāo)準(zhǔn)表都自帶了一些索引，這些索引大都比較實(shí)用。,創(chuàng)建索引需要注意以下幾點(diǎn)：（1）索引會(huì)占用額外的數(shù)據(jù)庫(kù)空間，還會(huì)降低插入/修改的速度（雖然可提高查詢速度），所以需要考慮實(shí)用性，肯定不是越多越好。如果表中已有類似的索引，則不推薦新建。而對(duì)于容量大的、被多個(gè)程序訪問的表加索引就更要謹(jǐn)慎了，比如VBFA、MSEG、FAGLFLEXA、LIPS、VBAP、EDIDC、STXH等等。（2）創(chuàng)建索引時(shí)應(yīng)注意字段的先后次序，MANDT是必須的而且都要放在第一位。字段的先后次序取決于實(shí)際業(yè)務(wù)需要。另外索引的字段不宜太多，字段越多占用的數(shù)據(jù)庫(kù)空間就越多，對(duì)于插入/修改的影響也更大。,7，選用一些替代表/替代字段（VBFA,SHP_IDX_）曾做過一些類似于“未揀配交貨單”、“未發(fā)貨過賬交貨單”的報(bào)表，剛開始用的是LIKP、VBUK等表，速度并不理想。后來調(diào)試了標(biāo)準(zhǔn)程序VL06O，發(fā)現(xiàn)其用的表是SHP_IDX_PICK、SHP_IDX_GDSI等。原來系統(tǒng)在創(chuàng)建交貨單的時(shí)候，也會(huì)更新這些臨時(shí)表。當(dāng)揀配完成，該條目就從SHP_IDX_PICK中刪除。所以表SHP_IDX_PICK的條目數(shù)始終不多，查詢速度很快。同樣的，當(dāng)我們?cè)诙鄠€(gè)表中進(jìn)行查詢時(shí)，可能不同的限制條件都能達(dá)到同樣的結(jié)果集，但效率差異就很大，所以選用有效的字段非常關(guān)鍵。比如需要查詢某銷售組織某天已發(fā)貨的銷售訂單，我們可以將VBAP與LIPS聯(lián)查。此時(shí)查詢條件VBAK-LIFSK=SPACE或VBAP-ABGRU=SPACE并不影響查詢結(jié)果，但它們可以在第一時(shí)間就排除大量無