非常感谢Lars的详细解释。 非常感激。 您提供的信息非常有用。

在我们的案例中，插入1.6亿条记录大约需要5到7个小时，而我们位于AWS托管的12 TB系统上。

根据您的回复，我们的系统似乎无法比较您的插入统计信息。

对我先前的评论进行了更正。 我已经检查了系统，我们正在使用HASH分区。

由于使用AMDP，因此"内部"表实际上是一个表变量，所有计算都在 INSERT语句。 这意味着，是花时间在计算结果还是在INSERT上，这并不明显。

我建议从那里开始寻找导致运行时间长的原因。

就并行工作而言，循环分区是最糟糕的选择，因为它无法预先确定哪些记录组将转到哪个分区。 审查此分区选择可能是个好主意。

对于500 Mio记录插入-只要有足够的内存来保持不断增长的增量存储结构，这当然不是问题。

您可能还想检查间歇性增量合并是否会对INSERT产生负面影响。 如果是这样，请考虑在INSERT过程中禁用AUTOMERGE。

非常感谢Lars。 明白了。 我将进一步查找带来插入数据的查询。

只是要了解"插入性能"在多大程度上取决于各种因素，但是主要取决于要插入此处的数据的创建，这是我进行的一次小测试的结果 一个HANA Express VM（4个核心CPU）。

/*
 SECS记录RECS_PER_SEC MERGE_CNT
 120 214,999,957 1,791,666.31 48
 120 257,499,485 2,145,829.04 45
 120 261,499,477 2,179,162.31 45
 124 82,499,835 56,321.25 96
 */

 ->差异是由于不同的配置，分区方案，提交频率等造成的。
 ->但是，在我的小型计算机上，插入速度约为2 Mio记录/秒不是问题。 仅存储500 Mio记录大约需要5分钟。

 您的过程需要多长时间？

您可以插入的数据大小没有限制，除了当时可用的HANA资源。

到 要执行可靠的大容量INSERT，使用小批量的并行流将是您要实现的解决方案。 在少量表中插入大量数据可能会给HANA带来很大负担，而单个INSERT失败或影响其他用户的风险通常会导致构建一种针对流数量和批处理大小可配置的机制。

从您的回复来看，我们的系统似乎无法比较您的插入统计信息。

是的，不！ 比较这些统计数据并不能提供有关系统性能如何以及您可以如何做的任何见识。

我所展示的是，可以在短时间内在HANA中插入许多行。 您的HANA中没有多少行。

它应该给您另一个指示，它可能不是花费大量时间的INSERT操作，而是您在创建数据之前运行的查询 被插入。 这是我开始寻求性能改进的地方。