在标准内部表上运行时，没有密钥说明的SORT语句到底能做什么？按照documentation：
如果未使用加号BY输入任何明确的排序键，则内部表itab将通过主表键进行排序。排序的优先级基于表定义中指定键字段的顺序。在标准键中，将根据表的行类型中键字段的顺序对排序进行优先级排序。如果标准表的主表键为空，则不进行排序。如果这是静态已知的，则语法检查将产生警告。
主表键being defined为：
每个内部表都有一个主表键，该键可以是自定义键或标准键。对于哈希表，主键是哈希键，对于排序表，主键是排序键。这两种表类型都是针对其键访问进行了优化的键表，因此主键具有自己的管理功能。当您访问各个行时，这些表的关键字段具有写保护。标准表也有一个主键，但是没有优化相应的访问，没有单独的键管理，并且键字段没有写保护。
为了很好，标准密钥is defined为：
内部表的主表键，其结构化行类型中的键字段都是具有字符型数据类型和字节型数据类型的所有表字段。如果行类型包含子结构，则将其分解为基本组件。如果行类型本身不是表类型，则非结构化行类型的标准键是整个表行。如果没有对应的表字段，或者行类型本身是表类型，则标准表中的标准键为空或不包含键字段。
所有这些主要只是让我感到困惑，因为我不确定我是否真的可以依靠基本的SORT语句来提供可靠或安全的结果。我真的应该在所有情况下都避免使用它，还是如果使用得当，是否有目的？
通过扩展，如果我想运行DELETE ADJACENT DUPLICATES FROM itab COMPARING ALL FIELDS，那么在简单的SORT itab.之后何时安全运行？只有在所有字段上都添加了密钥吗？仅当我具有包含clike和xsequence列的内部表时，才没有显式键吗？ 如果我想执行该DELETE语句，在内部表上运行的最佳SORT语句是什么？
答案 0 :(得分：5)
在任何情况下都应避免不使用BY的SORT，因为它“会使程序难以理解，甚至可能无法预测”（dixit ABAP documentation）。我认为，如果您不提及BY，则代码检查器中的静态检查会发出警告。您应该使用 SORT itab BY table_line ，其中table_line是一个特殊名称（“伪组件”），意思是“该行的所有字段”。
附录10小时后：不是您的问题，但是您也可以使用主键和辅助键定义内部表，这样就无需显式排序-DELETE ADJACENT DUPLICATES可以与任何这些键一起使用。 / p>
答案 1 :(得分：0)
内部表可以具有可以从itab所基于或指定的结构继承的键。如文档所述，没有sort的{{1}}按主键排序，并且假设内部表正确实现，是安全的。
我认为此功能被设计为动态功能，可与智能表键设计一起使用。如果正确完成，则by（不带sort）可以使您的程序将来适应表键的更改。 （因此，如果您的密钥发生更改，请对其进行排序）。当以奇怪的方式修改密钥时，可能会出现问题。
经验法则：
您的程序代码越具体，就越不容易出错（并且更安全）。
因此，by将始终通过这两个字段产生相同的排序。
应用程序中的动态组件使其具有更大的灵活性，但是当修改它们所依赖的东西时，往往会出现（通常很难注意到）错误。
因此，如果您在前面的示例中使用了2个关键字段，则在中间加1（假设在两个现有字段之间添加sort by key_id, key_date），排序结果可能会以您未曾想到的方式发生变化。
如果您有一种基于日期进行处理的算法，则该更改可能会破坏您的算法。
在您有key_is_active的特殊情况下，我会遵循 Sandra Rossi的建议。