您已经发现，工作负载管理是一个复杂的主题，因为您要处理动态情况以及目标冲突：

您想同时为每个语句提供最佳性能 避免系统因过多的请求而过载（这里有10个用户单击"狂野"并运行100个类似的查询，或者1000个只希望完成一个查询的用户，这并不重要）。

SPS 04 HANA提供了整套不同的功能，旨在解决问题的不同方面：

• CPU（在系统级运行于共享硬件上时，在OS级使用）
< li> CPU线程池（用于管理HANA内部每个查询的最大CPU使用率）
• 内存限制（用于OS级使用率和每个语句允许的数量）
• 准入 控制（以处理允许的并行会话数）

工作负载类和映射有助于对这些限制进行分组并将其分配给各个用户。 不必为每个用户创建单独的工作负载类，但是每个用户将具有一个映射。 这些映射可以过滤用户名，应用程序名称，应用程序组件等内容-如果应用程序提供了该信息（如许多SAP产品所做的那样）。

这样，就不那么困难了。 可以为BI用户或FIORI用户创建映射。

这些措施均不能直接解决您对超级点击用户的关注，因为HANA不会计算并检查是否存在来自同一用户的查询 同一用户已经在运行或尚未运行。 而且，实际上，这种工作量也可能有正当的理由（定期更新仪表板吗？）。

因此，您可以做的是 设置TOTAL STATEMENT THREAD LIMIT，以便其他工作负荷类仍然可以运行。

是否会降低每个用户的最大性能？ 当然可以。 但是，即使一种HANA使用者正在"狂野"运行，它也允许其他工作负载类运行。

如Mike所述，其他减少常规高资源查询影响的措施是：

• 良好的查询/数据模型设计
• 理解
• 利用诸如缓存视图和预先计算（取决于您的数据情况）之类的东西来回答的问题

尤其是最后一点可以 变得有争议，因为毕竟这是HANA，不需要进行任何预先计算。
实际上，在某些情况下，某些复杂的查询所需的时间比所需的时间长（例如，交互式显示平均需要10秒，而最多需要5（在案例中为95％）秒，则数据实际上不会更改 这么快。 考虑一下全球销售或库存KPI，其中数据提要大约每半天发送一次。
对于这种情况，缓存视图或预先计算的结果可能是一个很好的解决方案。
与往常一样，YMMV和"取决于"。

我希望能对您有所帮助。

干杯

Lars