ABAP 内表三种类型对比：STANDARD、SORTED 与 HASHED TABLE 如何选择

ABAP 内表是日常开发中最常用的数据结构之一。STANDARD TABLE、SORTED TABLE 和 HASHED TABLE 看起来都能存放多行数据，但它们在数据顺序、排序方式、Key 查找效率、重复 Key 规则和索引访问能力上有明显区别。

理解这三种表的差异，能帮助我们在写 READ TABLE、LOOP AT、ALV 输出、缓存查询和性能优化时做出更合适的选择。

一、三种内表的核心区别

简单来说：

• STANDARD TABLE 像普通列表，按插入顺序存放。
• SORTED TABLE 像自动排序的列表，始终按 Key 有序。
• HASHED TABLE 像内存中的字典或 Map，适合根据唯一 Key 快速定位。

二、STANDARD TABLE：最常见的标准表

STANDARD TABLE 是 ABAP 中最常见的内表类型。

DATA gt_data TYPE STANDARD TABLE OF ty_data.

它会按照数据插入顺序保存记录。比如插入顺序是：

3
1
5

实际保存结果仍然是：

3
1
5

当使用普通 Key 查找时：

READ TABLE gt_data
     WITH KEY id = '100'.

系统默认会从第一行开始，一直向后查找，直到找到目标记录或查完整张表。也就是说，如果内表有 100 万条数据，而目标数据在最后一行，理论上就可能需要比较 100 万次。

因此，STANDARD TABLE 默认 Key 查找的复杂度通常可以理解为：

O(n)

如果你已经手动排序，可以配合 BINARY SEARCH 提升查找效率：

SORT gt_data BY id.

READ TABLE gt_data
     WITH KEY id = lv_id
     BINARY SEARCH.

这种方式可以达到：

O(log n)

但要注意，使用 BINARY SEARCH 的前提是你必须自己保证内表已经按相同字段正确排序。

三、STANDARD TABLE 适合什么场景

STANDARD TABLE 最适合普通数据存放和顺序遍历，比如：

• 普通 LOOP AT 遍历
• ALV 输出数据
• 临时数据收集
• 数据量不大
• 不经常按 Key 查找

典型写法如下：

SELECT ...
  INTO TABLE gt_output.

LOOP AT gt_output INTO DATA(gs_output).
  " 处理输出数据
ENDLOOP.

在实际 SAP 项目里，如果只是取数、整理、输出，STANDARD TABLE 往往就是最自然的选择。

四、SORTED TABLE：自动按 Key 排序的内表

SORTED TABLE 的特点是插入数据时自动保持排序。

DATA gt_data TYPE SORTED TABLE OF ty_data
             WITH UNIQUE KEY id.

也可以定义为非唯一 Key：

DATA gt_data TYPE SORTED TABLE OF ty_data
             WITH NON-UNIQUE KEY id.

假设插入顺序是：

3
1
5
2

在 SORTED TABLE 中，实际保存顺序会自动变为：

1
2
3
5

因此你不需要再额外执行 SORT 来维持主键顺序。

当使用 Key 查找时：

READ TABLE gt_data
     WITH KEY id = 3.

系统可以利用有序结构进行二分查找。对于 100 万条数据，查找次数通常可以控制在大约 20 次左右，复杂度可以理解为：

O(log n)

五、SORTED TABLE 适合什么场景

SORTED TABLE 很适合既需要按 Key 查询，又希望数据保持有序的场景，例如：

• 经常 READ TABLE ... WITH KEY
• 经常按 Key 顺序处理数据
• 需要范围查询
• 需要使用 LOOP ... WHERE 过滤一段有序数据

例如：

LOOP AT gt_data INTO DATA(gs_data)
     WHERE bukrs = '1000'.
  " 处理公司代码 1000 的数据
ENDLOOP.

当内表本身已经按 Key 有序时，这类按键处理通常会比普通标准表更高效。

六、HASHED TABLE：适合唯一 Key 快速查找

HASHED TABLE 的核心特点是通过哈希方式定位数据。

DATA gt_data TYPE HASHED TABLE OF ty_data
             WITH UNIQUE KEY id.

它必须使用唯一 Key。与 STANDARD TABLE 和 SORTED TABLE 不同，HASHED TABLE 没有固定顺序。

例如插入顺序是：

3
1
5
2

内部实际存放顺序不可预测。不能认为它一定是：

1
2
3
5

也不能认为它仍然是：

3
1
5
2

查找时：

READ TABLE gt_data
     WITH KEY id = 3.

系统会根据 Key 计算哈希位置，平均复杂度可以理解为：

O(1)

所以，当数据量很大，并且主要操作是根据唯一 Key 精确查找时，HASHED TABLE 往往非常高效。

但是它不支持索引访问：

READ TABLE gt_data INDEX 3. " 不适用于 HASHED TABLE

也不能依赖区间式顺序处理，例如：

LOOP AT gt_data FROM 10 TO 20. " 不适用于 HASHED TABLE

因为哈希表本身没有可依赖的顺序。

七、一个经典性能例子

假设有两组数据：

销售订单 VBAK：100000 条
客户主数据 KNA1：10000 条

程序循环销售订单，并根据客户号去客户内表里查找客户信息：

LOOP AT gt_vbak INTO DATA(gs_vbak).

  READ TABLE gt_kna1 INTO DATA(gs_kna1)
       WITH KEY kunnr = gs_vbak-kunnr.

ENDLOOP.

如果 gt_kna1 是 STANDARD TABLE，并且没有排序和二分查找，那么每次读取都可能线性扫描客户表。整体比较次数可能接近：

100000 × 10000 = 1000000000

也就是约 10 亿次比较。

如果 gt_kna1 改成 HASHED TABLE，并用 kunnr 作为唯一 Key，那么每次订单循环只需要一次哈希定位。整体就更接近：

100000 次哈希查找

这类查找缓存场景，正是 HASHED TABLE 的典型优势。

八、如何选择内表类型

可以按照下面的规则快速判断：

更实用一点的经验法则是：

• 主要是 LOOP AT 遍历：优先用 STANDARD TABLE。
• 需要按键查询，还希望支持排序或范围查询：优先用 SORTED TABLE。
• 主要用途是根据唯一 Key 快速定位记录：优先用 HASHED TABLE。

在实际 SAP 开发中，STANDARD TABLE 使用最多；HASHED TABLE 常用于性能优化中的查找缓存；SORTED TABLE 则适合既需要快速查询，又需要按照 Key 有序处理的数据。