HANA:xsodata：第一次和第二次请求执行之间存在巨大的性能差距

如果我公开一个视图

CREATE VIEW myView AS
SELECT ...
FROM ...

经索达塔

service namespace "oData" {
    entity "mySchema"."myView" as "myView";
}

在创建视图后第一次获取/myView时，性能非常低：

但是：在再次执行相同的请求后（以及每次之后），性能就是我想要的：

问题:

• 为什么?

• 如何避免第一个长时间运行的请求

已尝试：

• 在HANA Studios sql控制台中执行sql探查器输出（无需准备语句）始终可以提供良好的性能

• 表热加载（

  LOAD myTable ALL；

  ）没有效果

更新

我们发现“为什么”——部分：xs引擎正在以准备好的语句运行查询，即使请求中没有参数。在第一次执行时（在用户的上下文中），查询将被复制，从而在

M\u SQL\u PLAN\u缓存中生成一个条目
（
SELECT*FROM M M M\u SQL\u PLAN\u CACHE，其中user\u NAME='myUser'
）。清除计划缓存（
ALTER SYSTEM CLEAR SQL plan cache
）会使oData请求再次变慢，从而导致假设性能差距在于查询的重新准备

我们现在陷入了第二个问题：如何避免这种情况？我们将某些计划缓存项标记为重新编译的方法（
ALTER SYSTEM RECOMPILE SQL计划缓存项123
）只是使该项无效，并且没有自动更新它…
我不确定您是否可以长时间删除第一次执行，但是您可以尝试将视图更改为在
SQL引擎中执行的计算视图

HANA
已针对使用其计算视图进行了超级优化，计划缓存应使用这些视图运行得更快，可能会显著减少首次执行时间。此外，计算视图的计划缓存应该在用户之间共享（因为生成它们的是
\u SYS\u REPO
）

如果您使用脚本版本，我相信您可以重用大量当前SQL，但也可以尝试使用图形化方法

如果你运气好，请告诉我们。使用大数据进行建模总是令人惊讶。
启用oData profiler：第一次执行查询比后续查询慢并不罕见。在第一次执行计划时，缓存的生成/优化和创建可能需要一些时间（取决于视图的复杂性和基础表的大小），但会被缓存，并在再次执行查询时可用。不幸的是，这会使我们的应用程序无法使用，因为语句准备是按用户进行的（查看
M_SQL_PLAN_CACHE
）。也许有一种方法可以“预取”或更新语句？
ALTER SYSTEM RECOMPILE SQL PLAN CACHE条目1234
只是“作废”条目（使请求再次变慢），但在没有“手动”请求的情况下不会更新它。。。