报表性能优化

1、精选ppt1ABAP：SAP报表的性能优化报表的性能优化v1、关于表连接语句（INNERJOIN,LEFTJOIN.）v写报表的时候，表与表之间的关联是不可避免的。通常而言，表连接语句要掌握的原则有：vv(1)将最有效的查询条件所对应的表放在第一位。换言之，让查询第一个表后所得到的结果集就尽可能小。v比如有一张报表叫做订单状态统计表，可能查完VBAK、VBAP后还查询LIPS、VTTP等，界面上的查询条件很多。不过据了解得知，该报表主要是查看昨天创建或前几天创建的订单。那么最有效的限制条件自然是订单创建日期，以及销售组织了，而表连接的主表宜选用VBAK。vv(2)确定了表连接的次序后，应考虑将

2、查询条件尽量限制在靠前的表里。比如选择屏幕上有个物料号的查询条件，而我们知道订单VBAP和交货单LIPS均有物料号，那就应该视情况而定，如果表连接中VBAP更早出现，那么WHERE子句中就使用vbapmatnrINs_matnr，反之就是lipsmatnrINs_matnr。vv(3)两个表之间进行连接的时候，应考虑关键字段或索引字段的作用。比如查询VTTP和LIPS时，关联关系是vttpvbeln=lipsvbeln。那么vttp在前，lips在后，就会比较快，因为根据vttp的vbeln查询lips时，vbeln是lips的关键字段，速度较快。而反过来如果lips在前，那根据lipsvbe

3、ln查询vttp会慢一些，除非vbeln是vttp的索引字段。精选ppt2v2，先构建RANGE再执行SQL语句v有时我们所能用的查询条件不是很理想，比如查询LIKP却必须用公司代码，而非销售组织。v此时普通做法是用LIKP与TVKO根据VKORG进行表联接，从而限制TVKOBUKRS的值。vv还有一种有效的办法是，通过TVKO查询到当期公司代码所对应的全部销售组织，从而组建一个RANGE出来，再根据此RANGE查询LIKP。当然要注意RANGE的行项目有上限的，在ECC6中大概2万行将导致ABAPDUMP。v提示：DATAr_vkorgTYPERANGEOFlikp-vkorg.vSIGN=

4、I,OPTION=EQ,LOW=XXXX即可往r_vkorg中放入多个单值。精选ppt3v3，ForAllEntries与SelectSingle的比较v就个人而言，笔者不是很喜欢ForAllEntries语句，因为它的缺点多于优点。很多人都会说，为什么呀，ForAllEntries不是比SelectSingle快么？事实到底怎样呢，让我们做个比较。v假设我们有个内表代表销售订单的行项目，该内表有10万行。此时我们要根据LIPS的VGBEL和VGPOS，查询这些订单行项目对应的交货单行项目。v精选ppt4精选ppt5vENDLOOP.vv对于SELECTSINGLE而言，由于LIPS有个VGB

5、的SAP自带索引，每次查询都挺快，即便循环10万次，速度虽然快不了但也没什么大的危害。v对于ForAllEntries的第一步，的确比SELECTSINGLE快些，本来10万次的SELECTSINGLE，变成了1万次的查询（如果BASIS设置了参数为10），每次查询10个订单行项目。但是第二步就很慢了，暂估it_lips为8万行，则对于it_vbap的10万个行项目，有8万个行项目执行READTABLE语句平均需要4万次才能搜索到it_lips的目标行，另有2万个行项目将读遍it_lips然后才发现没有对应的目标行。所以我们一共需要搜索48亿次，太慢了！vv在此针对ForAllEntries的

6、使用提出几点意见：v（1）如果是根据某数据量大的内表用ForAllEntries读取数据量小的配置表，比如TVAK/T006等，那不如把ForAllEntries直接去掉，把表里的几十条数据全部取出。精选ppt6v（2）使用ForAllEntries时，SELECT语句后面的字段必须包含所查表关键字段。比如上面的vbeln/posnr就是lips的关键字段。如果不含关键字段，比如SELECTlfimgFROMlipsForAllEntries*，那么当LIPS中两个条目关键字段不同而lfimg相同时，会被SAP自动过滤掉一条。v（3）上面关于性能问题，应该利用BINARYSEARCH、SORT

7、EDTABLE或者HASHEDTABLE来解决。详见下面第四节。vvv4，关于BINARYSEARCH/SORTEDTABLE/HASHEDTABLE的使用vBINARYSEARCH即二分法查找，在保证内表按查询字段以升序排列的时候，可以采用二分法查找。二分法查找的速度很快，最大查询次数为log2n。以上面的例子来说，如果it_lips事先按vgbel和vgpos排好序，则每次查找最多不超过17次。则对于it_vbap的10万个行项目，仅100多万次就可以搞定了！v当使用READTABLE语法时，如果查询字段跟SORTEDTABLE的排序开始字段能匹配上，则SAP将自动采用二分法查找。比如it

8、_lips是SORTEDTABLE且以vgbel和vgpos排序，则当readtable以vgbel进行查找时，系统会自动采用二分法。但如果readtable以vgpos和其他字段进行查找，由于vgpos并非SORTEDTABLE的第一排序字段，系统将采用直线查找，速度会慢很多。总之，SORTEDTABLE的排序字段次序也很关键。精选ppt7v针对STANDARDTABLE排序后可以进行二分法查找，使用SORTEDTABLE也可进行二分法查找，那么二者有什么区别呢？简单来说，由于SORTEDTABLE自始至终都保持排序，如果需要对内部进行频繁的插入、删除操作，则不推荐使用SORTEDTABLE

9、，性能会很差。而另一方面，如果我们要用的是类似LOOPATit_lipsWHEREvgbel=*的语法（而非READTABLE）时，对于STANDARDTABLE就无法采用二分法查找，或者说会很麻烦。而对于SORTEDTABLE，系统会自动采用二分法优化查找过程。vv至于HASHEDTABLE，笔者用得也不太多。查看SAP的标准代码，貌似用得也没很多。理论上HASHEDTABLE可以比SORTEDTABLE更快些，但需要耗用更大的存储空间。当某程序采用了二分法查找之后，如果效果还不是很理想，建议可以用HASHEDTABLE试试。精选ppt8v5，将循环内的重复性工作进行缓冲v有时我们的内表数据

10、量很大，但又不得不在每次循环的时候，都进行类似的一些操作，比如调用函数FI_PERIOD_DETERMINE获取某日期对应的会计年度和期间，调用函数MD_CONVERT_MATERIAL_UNIT进行单位转换，等等。每个函数的调用背后都要执行一系列的读表以及运算工作，程序的效率明显下降了。所以我们得想出有效的办法。vv比如针对FI_PERIOD_DETERMINE的调用，可以改用循环前对函数G_PERIODS_OF_YEAR_GET的调用。根据公司代码BUKRS读取T001-PERIV，然后调用G_PERIODS_OF_YEAR_GET获取某会计年度每个会计期间对应的起始日期和结束日期。这样在

11、循环内部，只要根据上面的结果即可算出某日期对应的会计年度和期间了。v又比如针对MD_CONVERT_MATERIAL_UNIT的调用。相信对于it_vbap的10万个行项目，物料号重复的有很多。所以可以先汇总物料号，然后一次性读取表MARM以存储换算关系。有了MARM的换算关系，循环中大量的单位换算就可以自己算了，如果无法换算的再考虑调用函数MD_CONVERT_MATERIAL_UNIT。（函数MD_CONVERT_MATERIAL_UNIT除了读取MARM的换算关系，还会考虑同一维度单位间的换算关系比如G和KG的关系，所以其功能更强大。）v精选ppt9v6，关于字段的增强以及TABLEIN

12、DEX的创建v这里提到字段的增强，主要是性能方面相关的。假设我们需要基于系统所有的billingdocument做个动作，比如将其导出到金税系统。至少有两种方案：第一是新建一个表，专门记录已经导出到金税的开票凭证；第二是在系统标准的开票凭证抬头表vbrk中新增一个字段，记录是否已导出到金税。v用户在处理业务的时候肯定会反复查询“未导出到金税”的所有开票凭证。那么第一种方案下，我们需要先查询VBRK表（比如得到1万条记录），然后针对自建表的记录（比如得到9800条记录）做个减法，最后得到200条记录的结果集。而第二种方案就快多了，查询VBRK的时候判断新字段=“未导出”即可。v随着业务的持续，V

13、BRK表的条目将越来越多，而“未导出”的条目则会维持在一个较为平稳的数字上，为了有效区分历史数据和现用数据，可添加TABLEINDEX，提高报表的查询速度。很多SAP标准表都自带了一些索引，这些索引大都比较实用。精选ppt10v创建索引需要注意以下几点：v（1）索引会占用额外的数据库空间，还会降低插入/修改的速度（虽然可提高查询速度），所以需要考虑实用性，肯定不是越多越好。如果表中已有类似的索引，则不推荐新建。而对于容量大的、被多个程序访问的表加索引就更要谨慎了，比如VBFA、MSEG、FAGLFLEXA、LIPS、VBAP、EDIDC、STXH等等。v（2）创建索引时应注意字段的先后次序，M

14、ANDT是必须的而且都要放在第一位。字段的先后次序取决于实际业务需要。另外索引的字段不宜太多，字段越多占用的数据库空间就越多，对于插入/修改的影响也更大。精选ppt11v7，选用一些替代表/替代字段（VBFA,SHP_IDX_）v曾做过一些类似于“未拣配交货单”、“未发货过账交货单”的报表，刚开始用的是LIKP、VBUK等表，速度并不理想。后来调试了标准程序VL06O，发现其用的表是SHP_IDX_PICK、SHP_IDX_GDSI等。原来系统在创建交货单的时候，也会更新这些临时表。当拣配完成，该条目就从SHP_IDX_PICK中删除。所以表SHP_IDX_PICK的条目数始终不多，查询速度很快。v同样的，当我们在多个表中进行查询时，可能不同的限制条件都能达到同样的结果集，但效率差异就很大，所以选用有效的字段非常关键。比如需要查询某销售组织某天已发货的销售订单，我们可以将VBAP与LIPS联查。此时查询条件VBAK-LIFSK=SPACE或VBAP-ABGRU=SPACE并不影响查询结果，但它们可以在第一时间就排除大量无关的