Database Indexes on SAP HANA for ABAP Developers

Traditional row-store database tuning often begins with B-tree secondary indexes. HANA's column store stores dictionary-encoded columns and can scan/filter columns efficiently in memory, changing the cost model. HANA can still use secondary indexes, including inverted indexes depending on table/design, but they are not universally beneficial. Selectivity, predicate columns, join cardinality, data distribution and statement frequency determine value. Indexes also consume memory and must be maintained on inserts/updates and during delta/main-store management. SAP-owned tables may have SAP-delivered indexes or application-specific guidance that custom indexes can interfere with during upgrade/support.

Consider an index only after a specific expensive SQL statement is proven with ST05/SQLM/HANA tools and the plan shows an access problem that an index can reasonably solve. First fix missing predicates, SELECT *, row-by-row calls, wrong joins, non-sargable expressions and data-model misuse. For custom large tables with a stable selective lookup pattern, an additional index can be justified. For standard SAP tables, follow SAP guidance/support process rather than adding production indexes based on generic tuning advice.

Index tuning is one layer below ABAP Open SQL. ST05 identifies expensive/repeated statements and transferred rows; HANA PlanViz/SQL Analyzer exposes operators/cardinality and whether an index is used. Table partitioning, data aging, CDS modeling and calculation pushdown can influence the same query. An index cannot fix an application that executes the statement 50,000 times unnecessarily.

A custom table holds 80 million integration events. A support query repeatedly filters by external message ID, which has very high selectivity, but the primary key is an internal UUID. ST05/HANA plan shows a large scan for each lookup. After workload review, the team creates an appropriate secondary index on the custom table and verifies reduced DB time, while measuring additional write/memory cost. They do not add indexes to unrelated SAP tables or to low-selectivity status columns.

S/4HANA depends on HANA and simplified data models, so many classic ECC index assumptions change. Some former aggregate/index tables disappeared because HANA can calculate from line items efficiently. Custom-code tuning should use HANA-aware evidence. Clean-core governance also discourages modifications to SAP-owned technical design without supported extension mechanisms.

ABAP developers identify the statement and reduce unnecessary access; HANA DB/performance specialists validate plan/index impact; data owners provide realistic cardinality/growth. Changes to standard SAP indexes require proper SAP/Basis governance.

ST05/SQLM find candidate SQL, DB02/DBACOCKPIT/HANA tools show database structures and workload, and the HANA PlanViz topic goes deeper into execution-plan analysis.

Production verification: Capture program and source line, selection or variant, realistic data volume, execution count, transferred rows, elapsed and database time, and the before and after trace. Use ST05 or SQLM for SQL evidence and SAT or ST12 for application runtime; optimize query shape and call frequency before changing indexes or adding parallelism.

Operational readiness: For production readiness of Database Indexes on SAP HANA for ABAP Developers, add one reproducible test case with realistic data volume and boundary values, one negative test that proves the failure contract, and one operational check that a support developer can run without changing productive data. Record the exact program, class or function and any release-dependent API assumptions. Where the topic affects performance or transaction consistency, compare evidence before and after the change instead of relying on coding folklore or one sandbox execution.