HANA中SELECT SINGLE与SELECT UP TO 1 ROWS的合规性及代码替换疑问

先把你的原代码和替换后的代码整理清楚，方便对比：

原代码：

SELECT SINGLE maktx 
  INTO tab-maktx 
  FROM makt 
 WHERE matnr EQ strmatnr 
   AND spras EQ sy-langu.

替换后的代码：

SELECT maktx UP TO 1 ROWS 
  INTO tab-maktx 
  FROM makt 
 WHERE matnr = strmatnr 
   AND spras = sy-langu 
 ORDER BY maktx.
ENDSELECT.

接下来咱们拆解HANA的合规要求和两者的核心差异：

1. 结果确定性是HANA的核心合规要求 #

你提到“仅获取单条记录时ORDER BY并无实际作用”，但这个结论在MAKT表的场景下不成立：
MAKT表的主键是MATNR + SPRAS + MAKTG（物料号+语言码+描述类型），这意味着同一个物料+语言组合下，可能存在多条不同描述类型的记录。

在传统行式数据库（比如Oracle、DB2）中，SELECT SINGLE会返回存储顺序中的第一条匹配记录，但HANA作为列式数据库，数据的物理存储顺序和传统库完全不同，SELECT SINGLE在没有明确排序规则的情况下，返回的是任意一条符合条件的记录——这会导致业务结果不可预测，而HANA要求所有业务逻辑必须保证结果的确定性，这是合规的核心要求之一。

替换后的代码通过ORDER BY maktx明确了排序规则，保证每次返回的都是排序后的第一条记录，结果完全可控。

2. HANA优化器对两种查询的处理差异 #

HANA的查询优化器对SELECT UP TO 1 ROWS的支持更友好：

• SELECT SINGLE在HANA中会尝试找到第一条匹配记录就停止，但如果没有合适的组合索引，它可能会扫描更多数据才能确定“第一条”；
• SELECT UP TO 1 ROWS结合ORDER BY会让优化器精准利用索引（比如MATNR+SPRAS+MAKTX的组合索引），直接定位到排序后的第一条记录，性能更稳定，也符合HANA的性能优化要求。

3. SAP官方HANA迁移的最佳实践要求 #

SAP在HANA迁移的官方指南中明确指出：

• 当查询条件无法保证唯一结果时，必须避免使用SELECT SINGLE，改用SELECT UP TO 1 ROWS并添加明确的ORDER BY子句；
• 即使你认为查询条件理论上唯一，也推荐使用SELECT UP TO 1 ROWS，因为HANA的存储模型可能导致SELECT SINGLE的行为和传统数据库不一致，引发潜在的业务问题。

总结一下：你的原代码不符合HANA合规要求的核心原因是无法保证查询结果的确定性，而替换后的代码通过明确排序规则解决了这个问题，同时也更适配HANA的性能优化逻辑。

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