ABAP性能和优化

哪些工具可以用于性能优化？

ST05-性能追踪。包含SQL追踪加RFC，队列和缓存追踪。SQL追踪主要用于测量程序中select语句的性能。

SE30-运行时分析。用于测量应用的性能。

SAT是过时的SE30的替代品。提供了和SE30相同的功能和额外的一些特性。

ST12事务（ST-A/PI软件组件的一部分）是ST05和SAT的结合。这是个非常强大的性能分析工具，由SAP提供支持。

Code Inspectior（SCI）是最好的静态性能分析工具之一。有很多选项可以用于找到通常的错误和可能的性能瓶颈。

优化ABAP代码的步骤

1，数据库

a. 在select语句中使用使用where子句来限制数据检索的体积。很重要！（译注：工作中见到过有人写select * from marc这种语句. 导致在生产系统中直接因为内存不足dump）

b. 设计查询，使其尽可能多地在where中使用索引字段。

c. 在select语句中使用inner（或者某些情况下使用outer）join语句以实现一次性查询得到匹配的数据。

d. 避免使用嵌套的select语句，以及loop中的select语句，使用join或者for all entries in会更好。如果已经有内表可以使用，或者在某些处理结束之后，可以使用for all entries in。如果select后面正好还有选择的话，使用join。

e. 访问缓存时避免使用into corresponding fields of table。相反，应该使用最适合程序的（字段）。

f. 避免使用select * ，应该只查询需要的字段。

g. 不要在select语句中使用order by，如果它和用到的索引不同的话（正确的做法是排序内表）。因为这会增加很多额外的工作。数据库系统只有一个，而ABAP服务器有好多。（译注：不确定这种观点在HANA平台中是否依旧适用。可以参考一篇在SCN上的问答，ABAP7.51版本的文档中已经删除了这个限制相关的描述：ABAP Development : SAP HANA ORDER BY or SORT internal table）

h. 索引。在为了改善性能而创建索引前，需要深思熟虑。索引可以提高查询性能，但是也会带来两个间接的负担：存储空间和写入性能。在大事务表中创建索引时，用于存储索引的空间和索引的体积是非常巨大的！当在数据库表中插入一条新的记录的时候，所有索引都需要更新。索引越多，花费的时间也就越多。数据越多，索引也就越大，更新索引所需的时间也就越大。

i. 避免多次运行相同的select（同样的select, 同样的参数）。在你的abap代码中缓存相关信息。

j. 如果有不影响性能的标准的视图，避免使用join语句。

2，表缓存

a. 将表定义为“缓冲过的”（SE11）可以提高性能，但是要小心地使用它。表的缓存会导致程序从缓存中而不是表中读取数据。缓存和表是周期性同步的，只有极少情况下、某些东西改变的时候才会同步。如果是事务表，数据在不同的选择条件下会改变，因此这类表是不适合缓存的。不建议在这种情况下使用缓存。应该为配置表和某些主数据表启用缓存。

b. 避免对缓存表使用复杂的查询，因为SAP可能解释不了这个请求，并且也许会把它传递给数据库——code inspector可以说明哪些命令会绕过缓存。

3，内表

a. 尽可能使用哈希表，其次是排序表。标准表是最后的选择。

b. 如果要修改内表的话，对于大工作区，应使用assign而不是loop into

c. 有疑问的时候，运行SE30，以此检查代码

d. 如果不得不用标准表，并且要read读取其中的行的话，使用binary search来提高搜索速度。

4，杂项

a. perform：写子程序的时候，总是提供所有参数的类型。这减少了系统根据形参确定参数类型的开销。这也提高了程序的健壮性。

select single和select ... up to 1 rows的区别是什么？

select single和select up to 1 rows返回第一条匹配给定条件的记录。它可能不是唯一的，给定条件有可能匹配多条记录。
对于oracle数据库而言，select single会被转换为select ... up to 1 rows，因此，它们是一样的。只不过ABAP的语法不允许将order by和select single放在一起用，但是允许其和select...up to 1 rows一起用。因此，如果你想获得最高/最低的一条记录，是不可以用select single的，只能用select ... up to 1 rows where ... order by.

join和for all entries in哪个性能好？

绝大多数场景下，inner join比for all entries in要好，应当被首先采用。只有当可能出现性能问题的时候才要用for all entries in，要仔细地测量更换为for all entries in前后的性能变化以验证是否真的有提升。

需要首先在一个测试程序上运行for all entries in并运行sql追踪以观察其效果。某些由BASIS设定的选项可以使for all entries in作为“OR”条件运行。这意味着如果使用for all entries in筛选的表有3条数据

，SQL追踪会显示3个SQL在执行。在这种情况下，使用for all entries in没意义。然而如果SQL追踪显示一条SQL语句，这时for all entries in是有用的，因为它实际上被当作一个in列表来执行。

比起for all entries in，更加推荐使用join。join连接的表的数量并没有实际的限制；不过太复杂的句子会难以维护，如果join里面有什么问题，也比较难以解决。如果join是使用两个表的键来连接的话，会减少程序负担，提高性能。

在某些场景下，你会需要以内表作为条件。此时，你可能没别的选择，只能用for all entries in了。

下面是使用了join的代码：

SELECT A~VBELN A~KUNNR A~KUNAG B~NAME1
INTO TABLE I_LIKP
FROM LIKP AS A
  INNER JOIN KNA1 AS B
    ON A~KUNNR = B~KUNNR.
* For with limited data using for all entries:
* Minimize entries in I_likp by deleting duplicate kunnr.
LOOP AT I_LIKP INTO W_LIKP.
  W_LIKP2-KUNAG = W_LIKP-KUNAG.
  APPEND W_LIKP2 TO I_LIKP2.
ENDLOOP.
SORT I_LIKP2 BY KUNNR.
DELETE ADJACENT DUPLICATES FROM I_LIKP2 COMPARING KUNNR.
* GET DATA FROM kna1
IF NOT I_LIKP2[] IS INITIAL.
  SELECT KUNNR NAME1
    INTO TABLE I_KNA1
    FROM KNA1
    FOR ALL ENTRIES IN I_LIKP2
    WHERE KUNNR = I_LIKP2-KUNNR.
ENDIF.

使用collect语句来在内表中求和

使用collect，而不是自定义逻辑来求和。对哈希表使用collect会很高效。

（译注：在使用HANA数据的情况下，利用Open SQL中的SUM关键字来求和似乎是更好的选择）

避免嵌套循环

例如：

LOOP AT ITAB1.

  LOOP AT ITAB2 WHERE F1 = ITAB1-F1.

    ....

  ENDLOOP.

  ENDLOOP.

在生成环境下，这样的代码可能会很慢甚至超时dump。

我们可以使用附加关键字binary search来改善性能。更好的是——使用哈希表或者排序表。

SORT ITAB2 BY F1.
LOOP AT ITAB1.
  READ TABLE ITAB2 WITH KEY F1 = ITAB1- BINARY SEARCH. "f1 is any field of itab1
  IF SY-SUBRC = 0.
    IDX = SY-TABIX.
    LOOP AT ITAB2 FROM IDX.
      IF ITAB2-F1 <> ITAB1-F1.
        EXIT.
      ENDIF.
      ....
    ENDLOOP.
  ENDIF.
ENDLOOP.

如果你有一个排序表，内表可以这样读取：

TYPES: BEGIN OF ITAB,
F1 TYPE MARA-MATNR,
....
*NOT ONLY THE KEYFIELD !!
END OF ITAB.
DATA: ITAB2 TYPE SORTED TABLE OF ITAB WITH UNIQUE KEY F1.
LOOP AT ITAB1.
  LOOP AT IATB2 WHERE F1 = ITAB1. "f1 is any field of itab1
  ....
  ENDLOOP.
ENDLOOP.