Read Table 的语法很多,这里说一种特殊情况,Read Table 中查询的时候对标准内表经常有一种二分优化查找,用Binary search的时候首先必须要有查询条件;但如果查询条件满足的项目不至一条时,这时得到的是这些数据中索引排在最前面的数据;
如: 001 0001 20100101
001 0001 20100103
001 0001 20100105
READ TABLE itab INTO wa WITH KEY col1 = ‘001‘ col2 = ‘0001‘ BINARY SEARCH.
这时得到的是第一条,001 0001 20100101 而不是 001 0001 20100103 这好像不符合二分法查找逻辑。按结果来看,这里的机制是先去匹配了查询条件,将匹配查询条件的数据全拉出来,然后取第一条,而不是按binary search 正常机制,先将low+high / 2位置的数据与条件匹配,成功就取出来。从结果来看,ABAP的二分机制实际是没用的。
然后做如下测试,先不对数据排序;
如: 001 0001 20100101
001 0002 20100103
001 0001 20100105
001 0003 20100105
001 0001 20100107
READ TABLE itab INTO wa WITH KEY col1 = ‘001‘ col2 = ‘0001‘ BINARY SEARCH.
得到的结果是001 0001 20100101 也是索引最低数据;
所以最好的解释:ABAP的二分查找机制是按位置n/2,n/4、、、再一半、、、直到最后一条数据;在这个过程中得到匹配数据仍然不停止将继续二分查找,不断的用新的匹配数据去匹配旧的数据;因为新的数据索引肯定比旧的索引低;
READ TABLE ..... BINARY SEARCH问题,布布扣,bubuko.com
READ TABLE ..... BINARY SEARCH问题
原文地址:http://www.cnblogs.com/ruingy/p/3759979.html