ABAP中SELECT SINGLE FROM内表与READ TABLE性能对比问询

核心结论 #

无任何筛选条件的场景下，READ TABLE的性能远优于SELECT SINGLE；带条件时的性能差异取决于筛选方式，且内表大小会放大这种差异。

1. 无筛选条件的场景对比 #

针对你给出的四个示例，性能从快到慢排序为：

• READ TABLE itab ASSIGNING FIELD-SYMBOL(<dat>)
• READ TABLE itab ASSIGNING FIELD-SYMBOL(<dat>) TRANSPORTING col
• SELECT SINGLE * FROM @itab INTO @DATA(dat)
• SELECT SINGLE col FROM @itab INTO @DATA(dat)

原因：SELECT SINGLE会触发OpenSQL解析器的完整流程——包括语法校验、内表转虚拟数据集、结果映射等额外开销；而READ TABLE是ABAP内核直接操作内表内存，没有这些冗余步骤。即使只读取单字段，TRANSPORTING的额外开销也远小于OpenSQL的解析成本。

2. 添加筛选条件后的性能变化 #

• 主键/唯一键匹配场景：
  READ TABLE ... WITH TABLE KEY（或使用主键字段的WITH KEY）的性能会碾压带WHERE条件的SELECT SINGLE。前者通过内表的主键索引/哈希表直接定位（O(1)时间复杂度），后者仍需走OpenSQL解析流程，即使WHERE条件匹配主键，也会多一层转换开销。
• 非主键字段匹配场景：
  两者都需要全表扫描，但READ TABLE ... WITH KEY依然比SELECT SINGLE ... WHERE更快——少了OpenSQL的解析和虚拟数据集转换开销。不过这种场景下，大数据量建议给内表创建二级索引，能大幅提升两者性能，但READ TABLE仍保持优势。

3. 内表大小对性能的影响 #

• 小内表（几千条数据）：两者性能差距不明显，但READ TABLE始终略快；
• 大内表（十万/百万级以上）：READ TABLE的优势会被显著放大。尤其是带键值查找的场景，READ TABLE的索引定位几乎不受数据量影响，而SELECT SINGLE的全表扫描开销随数据量线性增长，加上OpenSQL的固定解析开销，差距会越来越大。

补充说明 #

SELECT SINGLE的优势在于灵活性——支持聚合函数、多内表关联、复杂WHERE逻辑等OpenSQL语法，但如果只是单纯的内表单条读取（无论是否带简单键值条件），READ TABLE都是性能最优的选择。

内容的提问来源于stack exchange，提问作者Schesam