——-更新的答案（在实际测试了我的想法之后）

TL; DR

在这种情况下，运行时的差异来自于非常大的数据的卸载和重新加载 构成主键列的结构。

由于主键列只有唯一的值，因此与其他列相比，它不能被很好地压缩并且最终变得非常大。 HANA的内存管理试图通过尽早释放内存并在使用完后立即从内存中删除大的主键列数据来避免出现内存不足的情况。

下一次查询需要使用该数据时， 被重新加载到内存中-这需要很长时间（在这种情况下为几秒钟）。 更改"卸载"行为以将数据保留在内存中，使具有主键的查询与不具有主键的查询一样快。

可以在这里找到更详细的版本： https://lbreddemann.org/one -in-a-million/

——-

好，仅查询文本和您观察到的效果就没有太多要进行分析了。 我建议像往常一样使用EXPLAIN PLAN和PLANVIZ以获得更多的见解。

但是，我在这里有一个怀疑：

是否可能是其他三列（不是ID） 专栏）包含很多重复数据？

如果是这样，那么看到运行时的差异并不奇怪。
请参阅，HANA返回记录时，它会尝试尽可能长时间地使用实际值（值ID）的内部表示形式。 这是因为在许多情况下，这些值ID都小得多，并且可以轻松地使用SIMD指令进行处理。
仅当绝对需要记录字段的实际值时，例如 当应该将其交给客户时，将其填写。该过程称为"实现"，HANA尝试采用"后期实现"方法。

到目前为止，很好。

现在，使用包含100.000个不同值的列来运行查询。
HANA必须触及300.000个不同的值以实现所有结果记录。 太简单了，那就快了。

接下来，您运行相同的查询，但是包含ID列，根据定义，该列对于每个单个条目都具有不同的值。 在这里，HANA必须保留300.000 + 88Mio（或任何您的表计数）值，以准备实现记录。

我们可以假设通过值ID通过查询字典来查找实际值（ 即通过HASH函数-> O（1）），但查找88Mio记录仍比300K多两个数量级。

当然，最重要的是，要保留主键的88 Mio不可压缩值所需的额外内存。

此处要清楚，重要的一点是 主键仅包含唯一值。 如果表很大，则任何只包含唯一值的字段都会显示此效果。

这时，您可能会说："但是我只记录1000条记录"。

是的，但是TOP和LIMIT的定义要求将这些选项应用于最终 结果集显然必须先进行完全计算。

那么，您在这里可以做什么？

减少已处理的记录数。 放置一个对您的用例有意义的过滤条件。

谢谢，迈克-我注意到我的网站上有了新读者。 到现在为止最多有四个：D

傻事，您还没有收到有关此问题及其评论的通知...（我提过，我更喜欢旧的SDN论坛了... ？）

欢呼

Lars

您是否将此行为与其他大表进行了比较？ 毕竟，您有将近1亿个条目！ 在选择之后，您是否在最后而不是顶部尝试了limit命令？

您是否检查了两次调用中每个调用检索到的记录？ 因为我唯一能想到的是，带密钥的TOP 1000为您提供了ID最低的前1000个条目，而没有密钥的TOP 1000为您提供了"随机"的1000个条目，它们更容易实现 比具有主键的获取。 我找不到有关此假设的任何信息，但TOP n且未选择任何密钥。

嗨，迈克尔，谢谢您的答复。

您是否在选择后在末尾而不是在顶部尝试了limit命令？

我做到了，什么都没有改变。

您是否检查了两次调用中每一次检索到的记录？

对于两个查询，结果集都一样。

我仍在试图找出答案。

有两种想法，一种是表是否被索引。 可能应该是。 表中有多少个字段，是按行还是按列组织的（为了最好地使用HANA的功能，应采用柱状）。 其次是尝试在运行查询时按ID子句添加顺序。

如上所述，几乎有1亿条记录，这有点多余。 鉴于此，您的数据库管理员（DBA）对归档记录做了什么。 尽管它是HANA，但仍然需要执行优化任务以保持数据库有效运行。

干杯，迈克

嗨，亚历克斯，

我怀疑包括主键会导致所有记录在选择之前进行分析（这并不是很有效）。 如果对表进行索引，则可能会得到改善，但是我对索引和列表并不那么熟悉（如果此表和HANA属于这种情况）。 而没有主键的话，它只会抓取接收到的前1000条记录。 我认为可能需要与一个了解HANA工作原理的人一起审查内部工作原理，然后才能提供正确的答案。 如果可以提供表脚本，则可能会提供更多有关其行为方式的见解。

麦克，