为什么带有 ORDER BY PRIMARY KEY 的完整 TADIR select 比 INTO 排序的 table 慢得多？

Question

有以下说法：

SELECT * FROM tadir ORDER BY PRIMARY KEY INTO TABLE @DATA(lt_tadir).

DATA lt_tadir TYPE SORTED TABLE OF tadir WITH UNIQUE KEY pgmid object obj_name.`
SELECT * FROM tadir INTO TABLE @lt_tadir.

为什么第一个慢4倍左右（在多个系统上验证？文档中的相关声明：

For performance reasons, a sort should only take place in the database if supported by an index. This guaranteed only when ORDER BY PRIMARY KEY is specified

If a sorted resulting set is assigned to a sorted internal table, the internal table is sorted again according to the sorting instructions.

首先我认为列存储可能是个问题，但我尝试了另一个列存储 table，其中两个语句大致相似（尽管第二个似乎每次都快一点）。我测试的行存储也是如此。

此外，不知何故，我预计 ABAP 中的排序（第二个 Docu 已删除）会对性能产生影响。但它优于主键索引 select.

表没有完全缓冲，即使是这种情况，ORDER BY PRIMARY KEY 也会使用缓冲区。

有什么想法吗？

Answer 1

我运行测试（多次）并且两个语句的执行时间至少相似。应用服务器排序版本比 HANA 排序快约 25%。所以我的里程不同。

在您查看 table 定义之前，HANA 排序并不“更快”，这只会有点令人惊讶。对整个倒排哈希索引进行排序而不是它的设计目的。 :)

有些“规则”是用来打破的。
使用倒置哈希对 500 万个键进行排序可能是一个很好的例子。现在内存中有 500 万条记录，通过键快速读取行将有利于内部排序 table。无论如何 ;)

DATA lt_tadir TYPE SORTED TABLE OF tadir WITH UNIQUE KEY pgmid object obj_name

比简单的标准 Table 访问更友好。 @Data(lt_tab)

倒排哈希索引有一些已知的缺点。使用通常不会注意到的典型访问。 https://www.stechies.com/hana-inverted-individual-indexes-interview-questionsand-ans/

Answer 2

我想说这个性能测试毫无意义，从中得出的任何结论都是不正确的：

如果选择 整个 table，ABAP 中的排序和数据库中的排序只会产生相同的结果。如果结果数量有限（例如，获取最后 100 张发票），则在数据库上排序会产生正确的结果，而在 ABAP 中排序（在限制之后）则不会。由于很少有人选择 整个 table 测试用例是完全不现实的。
按主键（pgmid, object, obj_name）排序没有任何意义。在哪种情况下会有用？您可能想搜索某个对象，然后按 obj_name 排序可能会有用，或者您可能想查看最近传输的对象并按更正 (korrnum)
排序

只是为了演示运行下面的例子：

REPORT Z_SORT_PERF.

DATA:
  start TYPE timestampl,
  end   TYPE timestampl.

DATA(limit) = 10000.

* ------------- HANA UNCOMMON SORT ----------------------------------------

GET TIME STAMP FIELD start.
SELECT * FROM tadir ORDER BY PRIMARY KEY INTO TABLE @DATA(hana_uncommon) UP TO @limit ROWS.
GET TIME STAMP FIELD end.

WRITE |HANA uncommon sort: { cl_abap_tstmp=>subtract( tstmp1 = end tstmp2 = start ) }s|.
NEW-LINE.


* ------------- HANA COMMON SORT ----------------------------------------

GET TIME STAMP FIELD start.
SELECT * FROM tadir ORDER BY KORRNUM INTO TABLE @DATA(hana_common) UP TO @limit ROWS.
GET TIME STAMP FIELD end.

WRITE |HANA common sort: { cl_abap_tstmp=>subtract( tstmp1 = end tstmp2 = start ) }s|.
NEW-LINE.

在我的测试系统上，这个运行s 在 1.034s（不常见的）与 0.08s（常见的）中。那是 10 倍快 （尽管这种比较也没什么意义）。这是为什么？因为为 KORRNUM 字段定义了一个二级索引，正是为了这个目的（排序），而主键索引应该用于强制唯一性约束和检索单个记录。

一般来说，数据库并不是针对单个查询进行优化，而是针对整体系统性能（在内存限制下）进行优化。这通常是通过牺牲不常见查询的性能来优化常见查询来实现的。

For performance reasons, a sort should only take place in the database if supported by an index. This guaranteed only when ORDER BY PRIMARY KEY is specified

这是一个有点误导的表述。有些索引不是排序的最佳选择，虽然没有保证数据库会创建二级索引并在排序时使用它，但很有可能它在常见情况下会这样做。

为什么带有 ORDER BY PRIMARY KEY 的完整 TADIR select 比 INTO 排序的 table 慢得多？

Why is a full TADIR select with ORDER BY PRIMARY KEY much slower than INTO sorted table?

database

sorting

primary-key

abap

opensql