在标准内部表上运行时，没有键规范的 SORT 语句到底有什么作用？根据documentation：
如果使用添加BY未输入显式排序键，则内部表itab按主表键排序 . 排序的优先级基于表定义中指定键字段的顺序 . 在标准键中，根据表的行类型中键字段的顺序对排序进行优先级排序 . 如果标准表的主表键为空，则不进行排序 . 如果这是静态已知的，则语法检查会生成警告 .
使用主表键being defined作为：
每个内部表都有一个主表键，可以是自定义键或标准键 . 对于散列表，主键是散列键，对于排序表，主键是排序键 . 这两种表类型都是关键表，其关键访问权限已经过优化，因此主键具有自己的管理 . 访问各行时，这些表的关键字段将被写保护 . 标准表也有一个主键，但没有优化相应的访问权限，没有单独的密钥管理，并且密钥字段没有写保护 .
并且为了更好地衡量，标准键is defined如下：
内部表的主表键，其结构化行类型中的键字段都是具有字符数据类型和类字节数据类型的表字段 . 如果行类型包含子结构，则将它们分解为基本组件 . 如果行类型本身不是表类型，则非结构化行类型的标准键是整个表行 . 如果没有相应的表字段，或者行类型本身是表类型，则标准表中的标准键为空或不包含键字段 .
所有这些主要只是让我困惑，因为我不确定我是否真的可以依靠基本的 SORT 声明来提供可靠或安全的结果 . 我是否真的应该在所有情况下避免它或 does it have a purpose if used properly ？
通过扩展，如果我想运行一个 DELETE ADJACENT DUPLICATES FROM itab COMPARING ALL FIELDS ，那么在一个简单的 SORT itab. 后这样做是否安全？只有我在所有字段上添加了密钥？仅当我有一个包含 clike 和 xsequence 列的内部表时，没有显式键？ If I want to execute that DELETE statement, what is the most optimal SORT statement to run on the internal table?
2 回答
内部表可以具有可以从itab所基于或指定的结构继承的键 . 正如文档所述，
sort没有by按主键排序，而 is 安全假设内部表正确实现 .我 think 此功能被设计为与 smart table key design 一起使用的动态功能 . 如果正确完成，
sort没有by可以使您的程序适应未来的表键更改 . （因此，如果您的密钥发生变化，请随之改变排序） . 当以奇怪的方式修改密钥时可能会出现问题 .As rule of a thumb:
程序代码越具体，就越不容易出错（也就更安全） . 所以
sort by key_id, key_date将始终通过这两个字段产生相同的排序 .应用程序中的动态组件使其更加灵活，但是当他们依赖的东西被修改时，往往会出现（通常很难注意到）错误 . 因此，如果您使用前面的示例包含2个关键字段，则在中间添加1（假设在两个现有字段之间使用
key_is_active），排序结果可能会以您不期望的方式更改 . 如果您有一个基于日期处理的算法，那么您的算法可能会被该更改破坏 .在
delete adjacent的特定情况下，我会遵循 Sandra Rossi's 建议 .在所有情况下都应该避免没有BY的SORT，因为它是"makes the program difficult to understand and possibly unpredictable"（dixit ABAP documentation） . 我想如果你没有提到
BY，代码检查器中的静态检查会发出警告 . 你应该使用 SORT itab BY table_line ，其中table_line是一个特殊名称（"pseudo-component"），意思是"all fields of the line" .10小时后的附录：不是您的问题，但您也可以使用主键和辅助键定义内部表，这样您就不需要显式排序 - DELETE ADJACENT DUPLICATES可以与任何这些键一起使用 .