abap性能优化

转自：http://www.itpub.net/forum.php?mod=viewthread&tid=1714238&extra=&highlight=&page=1

ABAP程序的性能优化有几点非常重要。
第一，我们要尽可能的减少读取数据库的次数，尤其是在LOOP语句中使用select single 语句，而要把数据放到内表中，再使用read table 语句获取数据；
第二，尽可能不要使用SELECT * INTO CORESPONDING 语句，更好的办法是select A B into table的语句，因为在执行查询语句时，数据库会查询所有的字段，然后再匹配内表里面的字段。如果是select *，那么会对数据库进行全表扫描，这时候如果再遇到关联查询，效率可想而知。
第三，使用read table 语句的时候，尽可能使用binary search 语句，这个语句固化了二分查找算法，这对匹配数据来说非常有用，我就曾经因为使用了这个语句，把代码执行效率提升了好几倍。当然在使用binary search 语句的时候，要把内表按关键字排序。其实排序是个非常好的习惯；
第四，尽可能减少inner join的使用，可以把要关联的表放入内表，再使用read table 来匹配数据，因为关联查询的效率是非常低下的，即便一定要关联，也不要超过两个表，我个人推荐只关联两个表，三表关联的话效率就很低了，并且很有可能会导致数据错误；
第五，不要使用多重loop语句，也就是不要在loop语句里面嵌套loop语句。这不仅影响效率，对程序可读性也很有影响。
第六，是关于符号的，这点可能注意的人比较少，尽可能用EQ、NE来代替=、<> 等符号，因为用符号的话也会导致读取时效率降低；
第七，使用索引。这个一般都会用到，这里只是说一句，簇表不能加索引。
因为ABAP语言是解释型的程序设计语言，所以在执行上先天就比较慢，这就要求ABAP顾问对程序性能要比较好的优化，因为超时这种事，谁都不愿意看到。

ABAP程序的性能优化，这样表述可能更好一些：
1. 减少磁盘I/O次数，频繁读取数据表，是非常耗费时间的。所以在SAP需要读取某个表的数据，尽可能的一次性的放在内表中，这减少了IO，那些Loop中使用select是大量的增加了IO次数；减少I/O次数是最先要注意的。现在的内存数据库，其实也是使用大量的内存尽量减少IO的需要，在业务结束数据在归档到硬盘数据库中。

2. 提高I/O效率，比如查询尽可能用到利用主键、索引对于查询大表来说，是非常重要的。我有一个标准，如果查询一个数据库表，这个数据库表的数据超过10万，如果在SQL中没用到任何索引或者主键，这是不可以接受的。当时我们不能任意增加数据库表的索引，但是可以通过其他内表作为查询条件走一下弯路来尽量用到索引。

3. 提高CPU的效率，比如loop是比较费资源的，还使用折半查找binary search对于排序后的明显提高CPU搜索内存区域的效率。尤其是两个loop潜套，一般来说已经尽量避免，可以先整理数据，转化为loop和read table来提高性能。我们也可以建立一个标准，在一年的程序的开发中，你能使用两个loop潜套的机会只有5次，在程序中永远不能出现3次loop的情况，这样你就尽量少的使用loop嵌套了。

4.减少内存的耗用。尽量只选择需要的数据，只需要的字段到内存中来。及时不需要的内存。对于ECC程序来说，在程序运行时是一个事务性系统，所以我们可以利用报表程序的选择条件的配合，选择合适的从数据库表读取数据的顺序，可以大大的减少多余的内存耗用（之前，我们先读A表，然后B表，再C表，我们也可以根据选择条件，如果从C表先读取数据，再从A表读取数据，B表读取数据，内存可能会少用很多）。

5.对业务的更深入了解，可以得到更合理的程序编写和优化能力。尤其是SAP系统，要得到一个报表的结果，可能有多种从不同数据表获取的方法，但是有些可能较为曲折和低效，有些则可以提高效率。

6. 一些辅助的手段，类似于数据仓库技术（比如用额外的空间存储数据库的一些汇总数据）,从1个亿的表中访问数据和从一个10万的汇总表访问数据，差别会有很大的不同。比如很多企业都有大量的ecc的报表要获取每月历史物料的库存数据和月度消耗数据，如果大量的程序都平凡的从mseg中读取数据，效率不太好，可以考虑建议中间表，这个表示汇总的数据，其他的类似于同样计算需求的从这个中间表来访问数据。

从这个角度表述，更容易理解，而且这些性能优化的原则适用于所有的编程开发，无论是java还是其他编程语言。这也是最主要考虑的方面，至于说，某些语句的细节写法，并不是关键，比如有些喜欢用循环数据到fields symbols,有些喜欢循环数据到工作区，然后工作区修改后再修改内表，这些的细节的差别并不会导致性能差别很多（除非不同的语句导致CPU的算法或者数据库层面的底层磁盘操作的算法或者SQL执行路径有很大差异）。在性能优化一个程序时，关键要先找到那些地方在导致性能降低的时候起到主要作用，可以debug一下。我一般有一个标准，如果一个SQL读取出来的结果集少于1万条，那么如果超过1分钟，则一定需要优化，一分钟一万条是一个红线。在性能优化时，一般先看I/O次数（一般的中等复杂度的报表程序的I/O次数应该在10次以下）、I/O效率（大多数性能不好在于磁盘瓶颈），然后看内存耗用、CPU效率等。当然，有些语句，比如内表的排序表和哈希表，对这些表的查询，是用到了提高效率的专门算法，可以极大的提高CPU的效率，但是如果程序性能低下的瓶颈不在这方面的话，及时做这样的优化也不会整体提高程序的效率。