奇怪的INNER JOIN行为

2020-09-23 02:41发布

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


大家好,

我们正在重新设计一些程序,以使其更具可读性,更正其命名约定,更重要的是,提高它们的性能。

好的事情是,有很多事情要做(选择内部循环,重复选择,错误的选择...),因此,我们可以肯定的是,如果做得好,我们的工作将会带来良好的性能提升。

这是好奇心:

以下是旧程序的联接:

选择vbak〜vbeln vbak〜fmbdat vbak〜vbtyp
          vbap〜posnr vbap〜matnr vbap〜werks
          vbap〜klmeng vbap〜表示进入表wi_sel_order
                从vbak INNER JOIN vbap开
                     vbak〜vbeln = vbap〜vbeln
                           在s_auart中的vbak〜auart和
                                 vbak〜vdatu IN s_vdatu和
                                 vbak〜fmbdat在s_fmbdat中
                                 vbak〜vbeln在s_vbeln中
                                 vbak〜vkorg在s_vkorg中
                                 vbak〜vtweg IN s_vtweg AND
                                 vbak〜spart输入s_spart和
                                 vbap〜werks in s_werks AND
                                 vbap〜matnr在s_matnr中
                                 vbap〜pstyv IN s_pstyv AND
                                 vbap〜abgru IN s_abgru。
 

为了改善运行时间,我们重新安排了where子句:

选择vbak〜vbeln vbak〜fmbdat vbak〜vbtyp
          vbap〜posnr vbap〜matnr vbap〜werks vbap〜klmeng vbap〜meins
   进入表gt_sel_order
   从vbak INNER JOIN vbap ON(vbak〜vbeln = vbap〜vbeln)
   在so_matnr中的vbap〜matnr和
         vbak〜vkorg在so_vkorg中
         vbak〜vtweg在so_vtweg中
         vbak〜spart在so_spart中
         vbak〜auart在so_auart中
         vbak〜vbeln在so_vbeln中
         vbap〜werks在so_werks中
         vbak〜vdatu在so_vdatu中
         vbak〜fmbdat在so_mbdat中
         vbap〜pstyv在so_pstyv中
         vbap〜abgru IN so_abgru。
 

第二次连接速度更快,但返回的记录也要多于原始记录(40-50个条目)。

我们在Quick Viewer中测试了一个相同的查询,它返回的条目数与修改后的条目相同。

这使我们感到安慰,但我们无法解释。

关于为什么会这样的任何想法?

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


大家好,

我们正在重新设计一些程序,以使其更具可读性,更正其命名约定,更重要的是,提高它们的性能。

好的事情是,有很多事情要做(选择内部循环,重复选择,错误的选择...),因此,我们可以肯定的是,如果做得好,我们的工作将会带来良好的性能提升。

这是好奇心:

以下是旧程序的联接:

选择vbak〜vbeln vbak〜fmbdat vbak〜vbtyp
          vbap〜posnr vbap〜matnr vbap〜werks
          vbap〜klmeng vbap〜表示进入表wi_sel_order
                从vbak INNER JOIN vbap开
                     vbak〜vbeln = vbap〜vbeln
                           在s_auart中的vbak〜auart和
                                 vbak〜vdatu IN s_vdatu和
                                 vbak〜fmbdat在s_fmbdat中
                                 vbak〜vbeln在s_vbeln中
                                 vbak〜vkorg在s_vkorg中
                                 vbak〜vtweg IN s_vtweg AND
                                 vbak〜spart输入s_spart和
                                 vbap〜werks in s_werks AND
                                 vbap〜matnr在s_matnr中
                                 vbap〜pstyv IN s_pstyv AND
                                 vbap〜abgru IN s_abgru。
 

为了改善运行时间,我们重新安排了where子句:

选择vbak〜vbeln vbak〜fmbdat vbak〜vbtyp
          vbap〜posnr vbap〜matnr vbap〜werks vbap〜klmeng vbap〜meins
   进入表gt_sel_order
   从vbak INNER JOIN vbap ON(vbak〜vbeln = vbap〜vbeln)
   在so_matnr中的vbap〜matnr和
         vbak〜vkorg在so_vkorg中
         vbak〜vtweg在so_vtweg中
         vbak〜spart在so_spart中
         vbak〜auart在so_auart中
         vbak〜vbeln在so_vbeln中
         vbap〜werks在so_werks中
         vbak〜vdatu在so_vdatu中
         vbak〜fmbdat在so_mbdat中
         vbap〜pstyv在so_pstyv中
         vbap〜abgru IN so_abgru。
 

第二次连接速度更快,但返回的记录也要多于原始记录(40-50个条目)。

我们在Quick Viewer中测试了一个相同的查询,它返回的条目数与修改后的条目相同。

这使我们感到安慰,但我们无法解释。

关于为什么会这样的任何想法?

付费偷看设置
发送
6条回答
shere_lin
1楼 · 2020-09-23 02:58.采纳回答

您是否比较了SO_xxx和S_xxx选择范围的内容,SQL是相似的,因此选择标准必须有所不同,其中一些是通过代码构建的吗?

宇峰科技
2楼-- · 2020-09-23 02:51

" 第二个连接更快":不可能,两个查询都相同。 或者,如果速度更快,那显然是因为它们没有相同的WHERE选择。

南山jay
3楼-- · 2020-09-23 03:03

很好奇。 请同时运行SQL跟踪(ST05)和比较在数据库端生成的SELECT语句。

Aaron 3364
4楼-- · 2020-09-23 02:57

我很困惑,采用where-criteria的顺序会使任何有意义 差异。

那是我经验中的那些"城市神话"之一。

以%为单位的收益是多少?您是否多次运行了两个变体,并丢弃了第一个结果(缓冲效果)?

空代码
5楼-- · 2020-09-23 02:51

好主意。 没想到那个选择。 我会尝试的。

谢谢!

昵称总是被占用
6楼-- · 2020-09-23 02:53

Raymond,

我已经查看了范围(包括变体),但是我认为是罪魁祸首。 起初没有注意到。

关于"拒绝原因"的相同选择选项:两者都是空的,但是一个具有等号(仅查找空字段),而另一个没有等号(查找全部)。 我没有发现开发人员告诉我的相同差异,但这可能是由于使用的日期间隔。 无论如何,这两个程序的条目数相同。

让我回到他们在SAP的第一年,他们曾经告诉我们:" SAP永远是对的,继续寻找"。

Merci!

一周热门 更多>