版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/i042416/article/details/85000452
From: Wang, Jerry
Sent: Wednesday, March 19, 2014 11:54 AM
Subject: FW: custom development in IC search for Customer
下面是SAP CRM One Order搜索进入DB层处理的入口。
如果我只按照Service order的creation date搜，在后台的标准实现还是和我们own的product search类似，最后拼open sql。
拿到guid之后，再从index table里取其他字段:
之所以出现99.7%时间花在DB access on CRMD_ORDER_INDEX上，在于下图第40行的FOR ALL ENTIRES。后面跟的internal table it_guids_for_update里面entry越多，性能越差。
6259 records during Mar 9th 5-7 o’clock, 1244 during Mar 8th 21-23 o’clock
例如客户在周日上午5点到7点就有6259个新订单生成，那么一个月之内的订单数量是个非常庞大的数字，所以FOR ALL ENTRIES性能非常差。
但是第一个版本就用的For all entries，可能当初写代码的时候没有考虑潜在的性能问题。IBASE和PRODUCT的实现里都用的OPEN CURSOR +PACKAGE SIZE。
即使底层DB是HANA, 在数据库执行搜索时，FOR ALL ENTRIES IN it_table一样会把it_table里的所以entry展开成
IN( A, B, C, D, E … )的execution plan然后执行，效率不高。
