康拉德的答案通过消除双重否定（不喜欢）来解决问题的要点。

但是，这里还有两个方面需要提及。

1）更严重的是，LIKE表达式'％_A％'与OP似乎认为的不一样。 屏幕快照表明此表达式应匹配" ItemCode"以" _A"（下划线+ A）结尾的所有记录。
Like谓词使用下划线（ _）作为特殊字符，表示任何单个字符的匹配项。 要使LIKE谓词实际匹配下划线，必须将其"转义"。

要正确匹配以_A结尾的" ItemCodes"，LIKE谓词应如下所示：

"  ItemCode" LIKE'％/_ A'ESCAPE'/'

还请注意，LIKE模式的末尾没有％-否则该模式将匹配字符串中间带有_A的代码，如

这对于正确理解非常重要，因为否则会导致错误的结果集，并且很难正确设置。

2）如上所述，理解困难 原始的SQL代码是由于双重否定。 根据经验，建议在构建集合时选择选择/正条件，并使用集合操作（​​如NOT IN，MINUS等）从这些集合中排除数据。

对于此特定查询 ，主要目的是找到在OITM表的两个版本中都存在的项目（模式AA_CP中的一个项目和模式AA_SB中的一个项目），并排除以_A结尾的项目。
最后，应对OITB进行详细查找 提供" ItmsGrpName"

要做到这一点，另一种方法是使用具有适当连接条件的INNER JOIN，例如：

 SELECT
       a。" ItemCode" AS Codigo 
，a。" ItemName" AS Articulo 
，b。" ItmsGrpNam" AS Familia 
，a。" frozenFor" AS Activo 
 FROM 
 AA_CP.OITM  a 
 INNER JOIN AA_SB.OITM a2
       开启a。" ItemCode" = a2。" ItemCode"
      AND a2。" ItemCode"不喜欢'％/_ A'ESCAPE'/'

 左外连接AA_CP.OITB b 
上a。" ItmsGrpCod" = b。" ItmsGrpCod"; 
 
 

这里的优点不是执行性能或正确性之一-两种变体 实际上，由于HANA优化器重写了查询，因此得出了相同的执行计划。 尤其是存在第三个表具有相同名称，但在这种情况下，不同的模式更为明显。

而且，根据我的SQL经验，这使事情变得显而易见。 尽可能直接改善"阅读器性能"。