一个简单的需求，一个简单的SQL，执行起来竟慢的可怕。原因为何，如何解决，看我慢慢道来。
本文目录如下：
1、需求；2实现；3-11、问题分析解决；12总结
(1/12)需求
根据项目号，取WBS，然后根据AUFK~PSPEL=WBS，取AUFK和AFKO的数据。同时还需要根据WBS取一些额外的其他数据。
(2/12)实现
因为WBS还有它用，所以我先取出WBS，放到内表GT_PRPS中。
接下来，取AUFK和AFKO的逻辑如下：
(3/12)问题-第一步
执行时，发现执行的非常慢，然后用ST05(使用说明参见这里)进行执行计划分析，结果如下：
(4/12)问题解释-第一步
慢的原因有两个：
1、看上面where条件中，PSPEL IN中只有5个值，而我的GT_PRPS中条目数(是全都不重复的)，共有上万条。这样就相当于，这条语句要执行2000多次
2、下面红框框出来的部分，TABLE ACESS FULL AKFO。在AFKO和AUFK关联的时候，用的是AUFNR，这个字段是这两个表的主键。不知道为什么，这里没有通过主键的索引取值，而是执行了全表扫描。
擦嘞，这坑爹的执行计划！
(5/12)解决方案-第一步
为解决上述两个问题：
1、当for all entries in的内表，只用到一个字段时，使用hints改变SQL执行计划中IN的条目数
2、使用hints指定用表的哪个索引。为防止AUFK也出现不使用索引的情况，在此也为AUFK指定索引。
如下图：
解释如下：
1、T_00为AUFK，T_01为AFKO。AUFK~D为AUFK中包含PSPEL字段的索引，AFKO~0为AFKO的主键索引
2、prefer_in_itab_opt指定为1，表示将GT_PRPS中的值转为WHERE ... IN ..的方式，max_in_blocking_factor表示每个IN中最大的条目数，这极有效的减少了SQL执行的数量。
(6/12)问题-第二步
本以为执行结果应该正常，但是ST05的执行计划却如下：
(7/12)问题解释-第二步
ST05的执行计划显示，数据库首先进行了AFKO的SCAN，然后再进行了AUFK的SCAN。但是我们的查询条件是AUFK的PSPEL，这不符合我们的要求。所以，还是需要继续干预一下SQL的执行计划。
【注意：我也可以不通过AUFK和AFKO JOIN的方式来取数，改为两次for all entries in(先from aufk，再from afko)，但是需要定义额外的内表，并进行数据处理。而且我的目的是要优化这个简单SQL的执行计划】
(8/12)解决方案-第二步
干预SQL的执行计划，让它按照表出现的顺序来执行。
【此处，ordered也可以用leading代替。leading表示先访问AUFK，ordered表示按照AUFK、AFKO的顺序访问】
(9/12)问题-第三步
再次执行，查看执行计划，发现顺序是没问题了，但是执行计划中，表AFKO~0这个索引的使用方式存在问题。
(10/12)问题解释-第三步
查看AFKO~0的索引如下，包括MANDT和AUFNR两个字段：
数据库在ACCESS AFKO时，却只用到了索引中的MANDT，这没什么卵用啊。
再看6Hash Join时，才将AFKO和AUFK的数据进行匹配处理。
(11/12)解决方案-第三步
我初步猜测是因为JOIN的方式影响的，这种情况下，一般常见的都是NESTED LOOPS的JOIN方式。
于是，我写一个更简单的SQL来验证一下。
DATA: GT_AFKO TYPE TABLE OF AFKO.
SELECT * INTO CORRESPONDING FIELDS OF TABLE GT_AFKO
FROM AUFK INNER JOIN AFKO ON AFKO~AUFNR = AUFK~AUFNR
WHERE PSPEL = '00000001'.
然后ST05查看其执行计划，如下图：
果然，是NESTED LOOPS。
于是我继续加一个hints来干预执行计划，如下：
指定这两个表通过NESTED LOOP的方式关联。
【更多关于use_nl和use_hash的用法，请自行谷歌百度】
再次跟踪SQL执行计划，得到结果如图：
(12/12)最后
我尝试换了一些别的系统，执行同样的最初的SQL(不加HINTS的)，SQL执行计划各不相同。所以本文仅是针对特定数据库环境下的特殊结果，进行的执行计划分析与执行计划优化，供猿们探讨交流。
