我正在从SAP Core data Service (CDS view,SAP /3,ABAP7.50)读取数据,在其主(也是唯一的)键列上使用WHERE子句。使用FOR ALL ENTRIES时,性能会大幅下降(大约是原来的5倍):
在我的例子中,使用普通的WHERE子句读取数据大约需要10秒:
SELECT DISTINCT *
FROM ZMY_CDS_VIEW
WHERE prim_key_col eq 'mykey'
INTO TABLE @DATA(lt_table1).在我的例子中,使用带有相同WHERE的FOR ALL ENTRIES读取数据大约需要50秒:
"" boilerplate code that creates a table with one entry holding the same key value as above
TYPES: BEGIN OF t_kv,
key_value like ZMY_CDS_VIEW-prim_key_col,
END OF t_kv.
DATA lt_key_values TYPE TABLE OF t_kv.
DATA ls_key_value TYPE t_kv.
ls_key_value-key_value = 'mykey'.
APPEND ls_key_value TO lt_key_values.SELECT *
FROM ZMY_CDS_VIEW
FOR ALL ENTRIES IN @lt_key_values
WHERE prim_key_col eq @lt_key_values-key_value
INTO TABLE @DATA(lt_table2). 我不明白为什么在使用FOR ALL ENTRIES时,相同的选择需要五倍的时间。由于表lt_key_values只有1个条目,我希望数据库(在我的例子中,sy-dbsys是'DB6‘)执行完全相同的操作,外加一些可以忽略的小开销≪40。
从底层的SQL视图中进行选择而不是从CDS (及其访问控制等等)中进行选择根本没有区别,添加或删除DISTINCT关键字也没有区别(因为FOR ALL ENTRIES暗示DISTINCT)。
发布于 2019-06-12 20:31:22
一位同事猜测,FOR ALL ENTRIES实际上是在选择CDS的全部内容,并在运行时将其与内部表lt_key_values进行比较。这似乎是对的。
使用transaction st05,我记录了一个SQL跟踪,在FOR ALL ENTRIES的情况下,该跟踪如下所示:
SELECT
DISTINCT "ZMY_UNDERLYING_SQL_VIEW".*
FROM
"ZMY_UNDERLYING_SQL_VIEW",
TABLE( SAPTOOLS.MEMORY_TABLE( CAST( ? AS BLOB( 2G )) ) CARDINALITY 1 ) AS "t_00" ( "C_0" VARCHAR(30) )
WHERE
"ZMY_UNDERLYING_SQL_VIEW"."MANDT" = ?
AND "ZMY_UNDERLYING_SQL_VIEW"."PRIM_KEY_COL" = "t_00"."C_0"
[...]
Variables
A0(IT,13) = ITAB[1x1(20)]
A1(CH,10) = 'mykey'
A2(CH,3) = '100'因此实际发生的情况是: ABAP选择整个CDS内容,并将内部表中的值放入类似附加列的内容中。然后,它只保留内部表和SQL结果条目确实匹配的那些值。==>没有在数据库级别进行优化,=>性能不佳。
https://stackoverflow.com/questions/56556437
复制相似问题