嗨，

根据注释135048，SAP为两个语句添加了相同的Oracle提示FIRST_ROWS：UP TO x ROWS和SELECT SINGLE。 因此，应该没有太大的区别。 对于较新版本的Oracle，可能有所不同。 当我有完整的主键时使用SELECT SINGLE，而没有主键时则使用UP TO 1 ROWS。 您可以使用ST05确定哪种查询更适合您的情况。

干杯

• 如果仅在我们拥有所有主键时才使用SINGLE
• 当我们没有所有主键时，最多可以有1行。
• 在性能方面不会有重大区别，但是当我们使用多达1行时，数据可能会不一致。
• 如果未传递所有主键，则有机会在给定条件下拥有多个记录。 因此，这里最多1行支持排序以获取我们所需的记录。
• 如果使用UP TO 1 ROWS，则可以指定附加ORDER BY来确定多行匹配中的第一行。

我相信SELECT .. UP TO 1 ROWS在理论上具有更长的运行时间，尽管我非常确定它是不可测量的。 原因如下：如果调试该语句，您将看到它执行SELECT，然后转到ENDSELECT并返回到SELECT。 因此，解释器似乎只运行一次循环，而SELECT SINGLE只是一个语句。 （好吧，这无疑是一些挥霍的争论……）

在Oracle上，实际的数据库语句（本机SQL）相同：都使用提示FIRST_ROWS（1）并通过ROWNUM <= 1限制结果集。

齐格弗里德·波伊斯写道：

当我拥有完整的主键时，我使用SELECT SINGLE。

当我没有完整的主键时，我最多使用1行。

原因是代码的可读性而不是性能！

有趣并与他人保持一致，尽管总的来说，我不同意这一说法。 对我来说，SELECT SINGLE的惯用用法是只要您有条件确保只能返回一条记录。 一个唯一的索引（不仅仅是主键）就足够了，并且可能会争用应用程序/功能级别已知的唯一性来扩展它（公认的是更脆弱且不受控制）。

但是，就实际使用而言，我认为如果使用SELECT SINGLE时没有主键，则Extended Program Check会吐出警告（目前没有用于检查此内容的系统，如果这样，可能是 是否有这样做的强烈理由？！）。 我认为这是在没有完整主键的情况下采用SELECT ..最多1行的原因。

我一直不喜欢SELECT-ENDSELECT构造的部分是调试（提交）时可能出现短转储的可能性。 据我所知，这也适用于最多1行的限制，但不适用于SELECT SINGLE。

干杯，哈拉德

嗨，

当我具有完整的主键时，我使用SELECT SINGLE。
 当我没有完整的主键时，我最多使用1行。  

对不起，但这不是必需的，无论您想使用它是什么。

一个主要区别是对于所有枚举，它不适用于"选择单个"，而适用于"选择最多1行"

但是我认为SELECT SINGLE和SELECT UP TO 1 ROWS之间没有任何性能差异

种类Rgds

Ravi Lanjewar

编辑：Ravishankar Lanjewar，2010年7月8日上午11:49

Alejiandro Sensejl，

我花了最后2个小时比较并研究了上述陈述，但没有明确的结果。

也许您最好花一些时间来获取和分析数据库计划以进行具体的查询？ 然后，您可以决定在这种情况下哪种方法更好。

例如，在与您相同的Oracle系统和NW版本中，我编写了代码：

数据：ls_ekpo TYPE ekpo。

 单选*
   从ekpo
   旁路缓冲
   INTO ls_ekpo
   ebeln ='XXXXXXXXXX'。

 选择 *
   从ekpo
   最多1行
   旁路缓冲
   INTO ls_ekpo
   ebeln ='XXXXXXXXXX'。
 ENDSELECT。

然后使用ST05。

计划相同，SAP将提示FIRST_ROWS传递给Oracle，并使用rownum <= 1：

 SQL语句
 选择
/* +
   FIRST_ROWS（1）
 */
   *
 从
   " EKPO"
 哪里
   " MANDT" =：A0 AND" EBELN" =：A1 AND ROWNUM <=：A2
 执行计划
  选择语句（估计成本= 5，估计#行= 2）
   |
   -3个STOP键
       | 筛选谓词：ROWNUM <= TO_NUMBER（：A2）
       |
       -2通过索引行EKPO进行的表访问
           |  （估算费用= 5，估算#行= 2）
           | 估计。  CPU成本= 46.827估计值。  IO成本= 5
           |
           ------ 1 INDEX RANGE SCAN EKPO〜0
                   （估算费用= 4，估算#行= 18）
                   搜索列：2
                   估计。  CPU成本= 28.886估计值。  IO成本= 4
                   访问谓词：" MANDT" =：A0和" EBELN" =：A1 

Sandra，感谢您指出新旧调试器之间的区别，并参考了OSS注释。 实际上，我仍然经常使用旧的调试器，因为我一直在为打开的会话数而苦苦挣扎...

赫尔曼，对我来说总是很有趣的是，那些看似微不足道的问题对于理解事物在内部的运作方式是多么大的挑战。

就使用而言，我真的很喜欢在开发人员知道（在技术或功能/应用程序级别上）最多可以匹配一条记录的情况下使用SELECT SINGLE的想法。 很好，因为通过阅读代码，您可以隐式地学习有关数据模型的某些知识（尤其是如果不能通过查看技术元数据来导出 ）。 不幸的是，开发人员经常会出错，并使用SELECT SINGLE，他们应该为处理多条记录做好准备。 但是，在这种情况下，SELECT ..最多1行是错误的（因此，对于这种情况，我的理想解释是无助的，因为开发人员知道可能有多个记录匹配，但他只需要其中一个）。