Rarely-documented performance pitfalls

A few performance pitfalls almost never appear in the textbooks yet cause real damage in production. The first is `SELECT ... FOR UPDATE`: on HANA it acquires *write* locks, escalating contention, and many developers add it defensively when they only meant to read. Use it only when you genuinely need the consistency guarantee within the same transaction; otherwise you are serializing readers behind a lock they never needed.

The second is the counter anti-pattern: `UPDATE ... SET f = f + 1`. On HANA's MVCC storage, repeatedly incrementing the same column serializes the row's version chain heavily, so a hot counter becomes a contention point. For counters, use a dedicated number-range object, which is built to hand out values without serializing a row. The third is dynamic Open SQL — `SELECT ... FROM (dyntab)` and similar — which defeats both optimizer plan reuse and the static ATC checks, so you lose performance and analyzability at once.

The fourth is `INSERT ... ACCEPTING DUPLICATE KEYS`: it silently drops rows whose key already exists instead of dumping. That is occasionally exactly what you want, but it is a foot-gun if you did not plan for it — rows simply vanish with no error, and a later reconciliation finds fewer rows than were inserted. Each of these is invisible in a quick read of the code, which is precisely why they belong in a senior developer's checklist.

ABAPupdate zcounter
   set cnt = cnt + 1
 where mandt = @sy-mandt
   and id   = 'GLOBAL'.

ABAPcl_numberrange_runtime=>number_get(
  exporting
    nr_range_nr = '01'
    object      = 'ZORDERNO'
  importing
    number      = data(lv_next) ).

Source notes: clean-core-curriculum §7.5