Secondary Keys on ABAP Internal Tables

An internal table always has a primary key, and ABAP additionally supports named secondary sorted and hashed keys. A sorted secondary key creates a secondary table index and can be unique or non-unique; a hashed secondary key provides hash-based access and is unique. Statements must explicitly select a secondary key when needed, for example with USING KEY or KEY additions. SAP documentation notes that secondary keys improve access but cost memory and runtime to build or maintain. That trade-off makes them particularly valuable for tables filled once and read many times through more than one business key.

Use a secondary key when the same large in-memory dataset is repeatedly read by an access pattern that is not well served by the primary key. Typical cases include a standard table that must preserve input order but is also looked up thousands of times by document/item, or a hashed table that needs ordered iteration through another field combination. Avoid secondary keys when the table is tiny, changes constantly, or the alternative lookup happens only once. A second SELECT or different primary table type can sometimes be simpler.

Secondary keys are an in-memory indexing mechanism, analogous in purpose—not implementation—to database indexes. They work with READ TABLE, table expressions, LOOP, MODIFY, DELETE, FILTER and other internal-table statements that can name a key. They do not change the database query that originally filled the table. The design choice therefore comes after the database result set has been minimized and before hot loops are optimized. A useful review asks which keys are read often, which rows are changed often, and whether the index cost is amortized.

A batch program loads purchase-order items into a standard table because it must later reproduce the original order. During enrichment it repeatedly searches by material/plant and again by purchase-order/item. Instead of sorting and resorting the same standard table, the developer adds a named sorted secondary key for material/plant and a hashed secondary key for purchase-order/item. The loops explicitly select the appropriate key. Runtime drops because the table no longer performs repeated linear scans, while the primary sequence remains available for output.

Secondary internal-table keys are part of current ABAP and remain relevant on S/4HANA and ABAP Cloud. HANA optimizes database operations, not arbitrary in-memory scans after data has reached the ABAP application server. Modern code using table expressions can still benefit from named optimized keys, but the expression must be compatible with the chosen key to obtain the intended access path.

ABAP development owns the declaration and explicit key usage. Performance engineering should validate the benefit with SAT or controlled benchmarks on realistic row counts. Business owners define whether a key is truly unique; that semantic fact must not be guessed from test data.

The standard/sorted/hashed internal-table topic explains primary table categories. SAT can prove CPU spent in repeated internal-table lookups, while ST05 is for database access and cannot tell whether the ABAP table scan itself is the bottleneck.