问题已解决。

解决方案是使用mandt，bstyp和aedat为表ekko创建索引。

谢谢您的回答。

我已经检查了表lvl，并且在给定的时间间隔（7天）内，头层上只有大约50个项目，每个项目都有1个位置项。

嗨，

尝试检查并验证传递给类CL_SRA020_PO_TRACKING_API的方法的条目是否全部有效。 还要检查条目数据集是在表级别上是短期购买还是长期购买（这很繁琐，但是可以保证数据集本身是大是小）。

对此一无所知。 希望您能找到解决方案。

-PG

Ekko表大约有480k条目，而bstyp和aedat都没有ekko的索引。 那么，也许这就是为什么要花太长时间的原因？ 有什么想法吗？

如果lv_cursor是INITIAL。
 *获取标题，至少一项或供应商主数据中包含搜索文本的所有PO
     带lv_cursor FOR的打开光标
       选择h〜ebeln h〜aedat h〜bsart h〜ekgrp h〜ekorg h〜lifnr
              h〜内存h〜frgrl h〜waers
          从（（ekko AS h
                  内连接m_kreda AS l ON h〜lifnr EQ l〜lifnr）
                  内联ekpo AS i在h〜ebeln EQ i〜ebeln上）
                在哪里h〜bstyp = cl_mmpur_constants => bstyp_f
                  AND h〜loekz <>'L'
                  AND h〜aedat> iv_created_date
                  AND i〜loekz <>'L'
                  AND h〜bsart IN lt_auth_bsa" 1998858
                  AND h〜ekorg IN lt_auth_eko" 1998858
                  AND h〜ekgrp IN lt_auth_ekg" 1998858
                  AND i〜werks IN lt_auth_wrk" 1998858
                  AND（h〜ebeln like lv_search_text OR
                        h〜lifnr像lv_search_text或
                        l〜sortl喜欢lv_search_txt_uc或
                        l〜mcod1 LIKE lv_search_txt_uc或
                        i〜txz01喜欢lv_search_text或
                        我〜像lv_search_text或
                        i〜ematn Like lv_search_text）
                        ORDER BY h〜aedat降序h〜ebeln降序。
   万一。
 

嗨，

谢谢！

实际上，在访问数据库时，应该仔细考虑对索引的访问，以使程序尽可能高效。

在这里应该适当地使用'Where子句'，以便正确的索引应该以相同的顺序使用ST05或SE30来分析使用哪个索引。

希望有帮助，干杯！

-Pavan Golesar（PG）