ABAP：SAP报表的性能优化.docx

大部分ABAPer都是从SAP报表及打印开始学起的，大家也都认为写个SAP报表程序是最简单不过的事了。但是实际情况真的如此吗？写报表时除了保证数据的准确性，您可曾考虑过报表的性能问题吗？由于报表程序是被最多SAP用户所访问的，所以性能差的报表很可能会引来大量的抱怨和质疑，大大降低用户满意度。最近做了较多性能优化方面的工作，颇有感触，在此进行归纳总结，希望对大家有所帮助，也欢迎大家讨论。??1，??关于表连接语句（INNER JOIN, LEFT JOIN...）?写报表的时候，表与表之间的关联是不可避免的。通常而言，表连接语句要掌握的原则有：?(1)?将最有效的查询条件所对应的表放在第一位。换言之，让查询第一个表后所得到的结果集就尽可能小。比如有一张报表叫做订单状态统计表，可能查完VBAK、VBAP后还查询LIPS、VTTP等，界面上的查询条件很多。不过据了解得知，该报表主要是查看昨天创建或前几天创建的订单。那么最有效的限制条件自然是订单创建日期，以及销售组织了，而表连接的主表宜选用VBAK。?(2)?确定了表连接的次序后，应考虑将查询条件尽量限制在靠前的表里。比如选择屏幕上有个物料号的查询条件，而我们知道订单VBAP和交货单LIPS均有物料号，那就应该视情况而定，如果表连接中VBAP更早出现，那么WHERE子句中就使用vbap~matnr IN s_matnr，反之就是lips~matnr IN s_matnr。?(3)?两个表之间进行连接的时候，应考虑关键字段或索引字段的作用。比如查询VTTP和LIPS时，关联关系是vttp~vbeln = lips~vbeln。那么vttp在前，lips在后，就会比较快，因为根据vttp的vbeln查询lips时，vbeln是lips的关键字段，速度较快。而反过来如果lips在前，那根据lips~vbeln查询vttp会慢一些，除非vbeln是vttp的索引字段。??2，??先构建RANGE再执行SQL语句有时我们所能用的查询条件不是很理想，比如查询LIKP却必须用公司代码，而非销售组织。此时普通做法是用LIKP与TVKO根据VKORG进行表联接，从而限制TVKO~BUKRS的值。?还有一种有效的办法是，通过TVKO查询到当期公司代码所对应的全部销售组织，从而组建一个RANGE出来，再根据此RANGE查询LIKP。当然要注意RANGE的行项目有上限的，在ECC6中大概2万行将导致ABAP DUMP。提示：DATA r_vkorg TYPE RANGE OF likp-vkorg.SIGN = ‘I’, OPTION = ‘EQ’, LOW = ‘XXXX’?即可往r_vkorg中放入多个单值。??3，使用COLLECT的注意事项这里把COLLECT单独拎出来，并非排斥对它的使用。事实上COLLECT语句非常好用而且功能强大，却也因此往往被滥用。COLLECT一般是在LOOP循环内被使用，进行汇总运算。对于每个COLLECT wa INTO it_sum语句，系统会先查找内表it_sum中是否存在相同属性的条目，如果存在则在此条目上对数值进行叠加；如果不存在则新增一个条目。所以，这里涉及了查找的过程，而且该查找动作是在LOOP内进行的，是不是有点类似于嵌套循环？不过，ABAP早考虑到此因素。查看帮助发现，原来此查找过程采用了哈希法，怪不得程序性能依然很好。?但是，笔者曾经碰到过一个很慢的报表，仅仅通过对COLLECT语句进行调整，即大大优化了其性能。这是因为该报表没有考虑到以下2点：（1）it_sum中的非数值字段不应过多。上面说了，系统采用哈希法查找it_sum是否存在相同属性的条目。如果非数值字段过多，哈希法的性能将因运算量过大而急速下降。（2）it_sum的最终条目数应该少点。如果条目数增长过快，则查找过程的速度可能将受影响，从而影响性能。比如COLLECT vbak-vkorg可能比COLLECT vbak-vbeln会快些，因为前者的重复性高，结果集的条目数少。4，??For All Entries与Select Single的比较就个人而言，笔者不是很喜欢For All Entries语句，因为它的缺点多于优点。很多人都会说，为什么呀，For All Entries不是比Select Single快么？事实到底怎样呢，让我们做个比较。假设我们有个内表代表销售订单的行项目，该内表有10万行。此时我们要根据LIPS的VGBEL和VGPOS，查询这些订单行项目对应的交货单行项目。?如果用SELECT SINGLE的话写法很简单：LOOP AT it_vbap INTO wa_vbap.SELECT SINGLE vbelnposnrFROM lips INTO (wa_vbap-vb