哪些工具可以用於性能優化？
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.
CDS視圖性能分析
可以參看該文：使用PlanViz進行ABAP CDS性能分析
本文鏈接：http://www.cnblogs.com/hhelibeb/p/7043998.html
原文標題：ABAP Performance and Tuning