ABAP标准内表声明中键的含义及显式声明键字段的作用

在ABAP开发中，很多现有程序里的标准内表常采用无显式键的声明方式，示例如下：

TYPES type_itab TYPE STANDARD TABLE OF sflight WITH DEFAULT KEY.
DATA itab_0 TYPE type_itab.
DATA itab_1 TYPE TABLE OF sflight.
DATA itab_2 TYPE STANDARD TABLE OF sflight.
DATA itab_3 TYPE STANDARD TABLE OF sflight WITH DEFAULT KEY.
DATA itab_4 TYPE STANDARD TABLE OF sflight WITH EMPTY KEY.

这类内表通常搭配排序+二分查找的方式读取：

SORT itab_x BY carrid.
READ TABLE itab_x WITH KEY carrid = 'MH' BINARY SEARCH.

即便显式声明键字段（如DATA itab_5 TYPE STANDARD TABLE OF sflight WITH KEY carrid.），读取操作仍能正常执行且性能无差异，但显式声明键字段仍有不少实际价值：

• 提升代码可读性与意图清晰度：显式指定键字段能直接传递内表的核心检索用途，后续维护者无需从SORT、READ等语句中反向推导业务检索维度，比如声明WITH KEY carrid时，一眼就能明白该内表主要围绕航班公司代码做检索操作。
• 规避默认键的潜在风险：默认键（WITH DEFAULT KEY）会包含行结构中所有非内表、非引用类型的字段，若后续行结构新增字段，默认键会自动扩展，可能导致原本的SORT排序键与READ检索键不匹配，进而引发二分查找失效。显式声明键字段后，结构变更不会影响键的组成，逻辑稳定性更强。
• 强化编译期约束与错误检查：显式声明键后，当使用READ TABLE或LOOP AT ... WHERE时，若引用非键字段做检索，开发者能快速意识到这可能不是最优检索逻辑；同时编译器可更精准地检查键字段的合法性，减少拼写错误导致的运行时问题。
• 降低后续表类型重构成本：如果后续需要将标准内表改为排序表或哈希表，显式声明的键字段可直接复用，无需重新定义键结构，比如从标准表改为排序表时，只需调整为SORTED TABLE OF sflight WITH UNIQUE KEY carrid即可。
• 明确业务检索边界：相较于WITH EMPTY KEY（无默认键），显式声明键字段是明确指定了合法的检索维度，更贴合业务逻辑，避免了无键状态下检索字段随意性带来的混乱。

内容的提问来源于stack exchange，提问作者Sandra Rossi