任何与性能有关的调查都应从使用SQL跟踪（ST05）并检查执行路径开始。 （HANA系统中也可以存在其他工具，但我认为这里不是这种情况。）

只能通过主键或辅助索引来实现对数据库级别的快速访问。 就是这样。 我猜您的系统中没有适合LIKP或LIPS的二级索引，因此它必须遍历所有记录（也称为"全表扫描"）以找到与选择标准匹配的记录。 尽管它可能只找到4条甚至0条匹配记录，但仍然只花时间查找它们。 想象一下，如果您将一袋大米和一袋豆混合在一起，然后必须找到所有长于3毫米的米粒。 一样的东西，但是带有数据。

我对Bartosz的将SELECT分成两个多带带的建议感到困惑。 尽管并不是不可能提高性能，但是我发现DB优化器没有更有效地处理它是奇怪的。 这可能是YMMV情况，它可能基于数据库甚至特定的SAP系统而有所不同。 同样，二级索引仍然可能是更好的解决方案。

性能调优并不是一门精确的科学，因此，最好的选择是使用DB工具并在特定系统中进行实验。 如果您需要使用工具或解释发现方面的帮助，请联系当地的Basis管理员或DBA。

有关SQL性能问题的任何帖子，请提供输入变量的值和执行计划 ，因为它仅取决于您的数据。

您好 Santosh Nadumani

BartoszZiólkowski的解决方案是一个好主意。 它可以工作。 您应该尝试一下

如果没有，请检查报告的选择标准-是否有任何标记为必填字段？ 如果是，那么您可以使用这些字段（和MANDT字段）在表上创建数据库索引-这将有助于提高性能。

如果没有任何字段被标记为必填项（也许应该更改？） ，然后询问用户他们使用最多的字段，并根据这些字段创建数据库索引。

亲切的问候

Mateusz

likp -and-lips.jpg

桑德拉，你好

我将根据以下输入进行选择，仅从这4个整体中获取，但仍需要5至10分钟。

PFA屏幕截图

您好 Santosh Nadumani ，

I 曾经有过类似的问题，在我的情况下，解决方案将这两个选择分开-首先，我从LIKP中选择了VBELN（使用适用于LIKP的选择条件），然后让文档编号使用FOR ALL ENTRIES和选择条件从LIPS中执行了另一个选择 适用于LIPS（然后删除从LIKP收集的LIPS中不存在的条目）。
我不会说这是一种优雅的解决方案，但就我而言，它是一种魅力。
如果有人有更好的建议，我会很高兴听到。

致谢，
Bartosz

您可以上传解释功能的输出，还是在 HDB是PlanViz文件吗？