插入和数据加载将写入新数据，而SELECT、UPDATE或DELETE等其他操作必须对现有数据进行操作。
因此，典型的性能因素是部分不同的。如果你想提高插入和数据加载的性能，你可以考虑以下方面:
Area Details
Lock waits
参见1999998，如果需要，优化锁等待情况。插入必须等待锁的典型情况是:
- 重要的保存点阶段
- 同一主键的并发插入
- SAP HANA内部锁
- 同一表上的DDL操作已激活
Columns
在插入期间，必须分别维护每一列，因此插入时间在很大程度上取决于表列的数量。
Indexes
每个现有索引都会减慢插入操作的速度。检查是否可以在大量插入和数据加载期间减少索引的数量。SAP BW提供了在数据加载期间自动删除和重新创建索引的可能性。主索引通常不能被删除。
Bulk load
如果加载了大量记录，就不应该对每条记录执行插入。相反，您应该尽可能利用批量加载选项(即使用单个插入操作插入多个记录)。
Parallelism
如果加载了大量记录，则应该考虑客户端上的并行性，以便使用到SAP HANA的多个连接来加载数据。
Commits
确保在执行大规模插入时定期执行COMMIT (after each bulk of a bulk load)。
Delta merge
大的增量存储会降低负载性能，所以要确保定期执行增量合并。
避免重复合并小的增量存储或使用大量未提交的数据，以避免不必要的开销。
Table vs. record lock
如果只可能进行一次非并行插入，并且不需要对底层表进行并发更改，那么使用全局表锁而不是大量的单独记录锁可能会很有用。表锁可以通过以下方式设置:
LOCK TABLE "<table_name>" IN EXCLUSIVE MODE
之后，SAP HANA不再需要维护单独的记录锁。这种方法也适用于INSERT…选择可以在内部并行化的操作。
Savepoints
需要保存点将修改后的数据写入磁盘。通常的主要意图是尽可能缩短阻塞保存点阶段，同时接受较长的保存点持续时间。在大量导入期间，相反的情况可能更好:保存点更短，阻塞阶段增加的风险更大。较短的保存点可以减少写入磁盘的数据量，还可以减少需要保留的日志量，从而降低文件系统溢出的风险。
在大量更改期间，可以考虑以下参数调整来减少总体保存点持续时间:
- lower values for global.ini -> [persistence] -> savepoint_max_pre_critical_flush_duration (e.g. 300 instead of 900)
- higher values for global.ini -> [persistence] -> savepoint_pre_critical_flush_retry_threshold (e.g. 10000 instead of 3000)
Bugs
以下SAP HANA bug可能会对插入性能产生负面影响:
Impacted RevisionsDetails 1.00.120 - 1.00.122.11
2.00.000 - 2.00.012.00如果大量的空间数据是在没有提交的情况下逐行插入的，那么由于SAP HANA bug和调用堆栈模块AttributeEngine::spatialae::DeltaComponents::reserveDocid所花费的大量时间，性能可能会很差。作为“GeometryDeltaAttribute锁”上的次要影响争用是可能的。
典型的吞吐量
- 问题情况，如长临界保存点阶段或其他锁
- < 500 records / second
- 正常的、连续的单行插入
- 1,000 - 10,000 records / second
- 高度并行的批量加载
- 1,000,000 records / second
