关于For all entries Posted on 2013-04-26 16:20 rootbin 阅读(264) 评论(0) 编辑 收藏 举报
去从年开始写abap,就对for all entries的使用一直有疑问,当时带我的同事推荐我用这玩意儿
这期间除了筛选出的重复数据被删除外,没遇到什么大的问题,关于这点,多筛选几个key field就可以避免
性能也基本说的过去
前些天优化了一个程序
方案是: 把两张表的关联查询分开来处理
这过程中把表A的查询结果放到for all entries in <itab>中查询表B,这个内表的记录数量在30W+
这也是逼不得已这么做的,本以为还是跑不出结果的,测试后发现能出结果了,汗…
修改前程序后台运行超时,修改后在20mins左右
之后一直对for all entries 的处理方式很好奇.
1)关于for all entries的解析
使用or 来连接多个条件
例如: for all entries in i_tab where a = itab-a and b = i_tab-b
itab中两条记录
a1 b1
a2 b2
那么解析的sql语句中使用or连接
where ( a = a1 and b = b1 ) or ( a = a2 and b = b2 )
2)解析时有个限制
过多的or造成了sql语句的复杂度
导致查询优化器无法选择最优方案
反而可能选了个最差的方案 由此造成性能问题
为了避免这个问题
在itab的记录转换为or连接的条件时,支持多少条件个是有限制的
默认是10个
这样例如500条记录的内表 ,实际生成50个sql语句,
即使如此,还是存在复杂度过大的问题
于是极端的方案是设置分拆的数量为1个
这样就等效到loop中执行查询了!!
也并不是我们想要的
这大致就是for all entries的解析方式了
由于使用了or的问题,不得不联想到是否使用索引的问题,由于自己的开发也是很上层的,
不用考虑这么多,简单的操作,尽量让查询的条件是被索引的字段,并按照这些字段在表中的顺序排列
这样该用索引的还是会用的
根据一些网友的描述,由于for all entries会解析成多次查询的方式
总觉的有浪费(至少心里不舒服…)所以不推荐用这个方式
个人觉得如果关联查询能解决的话,就用连接查询就可以了
如果要用,注意其他的查询条件,尽量使用索引,避免range变量以及不确定判断等等操作
目的是减少单次操作时间 那么即使for all entries 分成多次查询也不至于成为瓶颈
总结下使用for all entries的场景:
1.簇表由于不能级联操作
2.关联查询有效率问题 (也是本次优化程序的情况,下次单独写一篇分析这个程序吧)
3.我们这边开发要求关联不要超过三张表,所以为了满足需业务求,好多时候都要用for all entries来满足需求 …
至少目前为止,没有遇到for all entires导致的性能问题
有也是因为其他条件使用不当导致的,使用for之后放大了这个结果
附:
1.for all entries 效率分析的文章:
http://blog.sina.com.cn/s/blog_6ddfd8060100mufg.html
2.Note 531337 - iSeries: Performance with Open SQL "FOR ALL ENTRIES"
http://www.stechno.net/sap-notes.html?view=sapnote&id=531337
文章来自于网络,如果侵犯了您的权益,请联系站长删除!