SAP HANA XS 数据库视图

Question

我刚开始支持在本地 HANA XS 上构建 SQL 视图，并遇到了我无法解释的系统行为。

有一个 SQL 视图，可以从多个表中进行选择，包括。 JCDS。当视图调用过于频繁时，系统会达到 cpu 限制。视图中唯一的大表是 JCDS，它有 4 个键 MANDT、OBJNR、STAT、CHGNR 和约 30 亿条条目。所有其他表都小得多。 在分析视图时，我看到 JCDS 中的数据是根据 OBJNR 和 STAT 选择的。

由于没有维护 MANDT，我假设不使用索引搜索，而是执行全表扫描。当使用给定的过滤条件从 JCDS 执行单行选择时，我得到的响应时间约为 90 毫秒（> 81 毫秒 && <97ms). When also adding the field for MANDT I get a response time that is on average 76ms.

维护附加关键字段时似乎没有相关的性能提升。

这是否可以解释为整个表已经存储在内存中并且索引的二分查找没有太大影响？

HANA XS 中的密钥是否以分层方式使用？当我只维护 4 个关键字段中的前 3 个时，这是否已经限制了基于二分搜索的结果？或者只有在键被完全维护时才执行索引搜索？

您能否向我推荐一份文档，我可以用它来收集有关在 HANA XS 中开发视图的更多知识？

Select * from JCDS where OBJNR = $OBJNR and STAT = $STAT

==> 平均响应时间 90ms

Select * from JCDS where MANDT = 100 and OBJNR = $OBJNR and STAT = $STAT

==> 平均响应时间 76ms

Answer 1

StackOverflow 是一个社区，人们免费贡献自己的时间，尽最大努力帮助处于类似情况的人们，而无需了解情况的完整背景。

抱歉，您说的是 SAP HANA。这是一个企业级商业产品，您的雇主决定投资数百万美元，而您首当其冲。

我对你有感觉，真的。但这不是 StackOverflow 可以帮助您解决的问题。这是您的雇主与 SAP 之间针对已购买的 SAP HANA 产品的支持合同的问题。

老实说，听起来像是一个基本的资源问题。 SAP HANA 是一个内存数据库。资源极度匮乏。引用《大白鲨》的话...你需要一艘更大的船...

但老实说，您只需向 SAP 提出支持票即可解决此问题。这就是为什么您的公司要向他们支付数百万英镑来购买他们的“很棒的软件”。对于你个人来说，作为一名员工，你完全有权利走这条路，你不是 SAP HANNA 之神，所以不要把这个担在你的肩上。

这些事情是组织的选择。你只是一个凡人，碰巧选择在你生命的这段时期在上述组织工作。