ABAP SQL 튜닝 시리즈 두 번째 글입니다.
성능 리뷰를 하다 보면 반복해서 만나는 패턴입니다.
DB는 전건을 읽어 네트워크로 전부 보내고, ABAP은 그중 대부분을 버립니다. 양쪽 다 낭비입니다.
조건을 WHERE절로 내려보냅니다. DB가 인덱스로 필요한 행만 찾아 돌려줍니다.
CHECK나 DELETE ... WHERE 로 내부 테이블을 거르는 코드가 보이면, 그 조건이 왜 WHERE절에 없는지 먼저 의심하세요. 대부분은 그냥 옮기면 됩니다.
WHERE절을 썼다고 항상 빨라지는 건 아닙니다. DB가 인덱스를 탈 수 있어야 합니다.
인덱스는 여러 필드를 정해진 순서로 묶어놓은 목록입니다. 전화번호부가 "성 → 이름" 순으로 정렬된 것과 같습니다.
인덱스가 (MANDT, BUKRS, GJAHR) 순이라면, 앞에서부터 연속으로 조건을 주어야 효율이 납니다.
BUKRS 없이 GJAHR만 주면, 전화번호부에서 성을 모른 채 이름만으로 찾는 것과 같습니다.
특히 LIKE '%...' 처럼 앞이 열린 패턴은 인덱스를 앞에서부터 훑을 수 없어 효율이 급격히 떨어집니다.
조건을 짤 때 스스로에게 물어보세요. "이 조건으로 전체의 몇 %가 남는가?" 90%가 남는 조건이라면 인덱스는 도움이 안 됩니다. 선택도가 높은(적게 남는) 조건이 앞에 있어야 합니다.
인덱스를 타는지 추측하지 말고 확인하세요. ST05에서 해당 SQL을 잡은 뒤 실행 계획(Explain) 을 보면, DB가 어떤 경로로 데이터를 찾았는지 나옵니다.
여기서 전체 스캔이 보이는데 결과 건수가 적다면, 조건이나 인덱스에 문제가 있다는 신호입니다.
전통적인 디스크 기반 DB 시절의 습관을 그대로 가져오면 안 되는 영역입니다.
느린 쿼리가 있으면 인덱스를 만들어 해결하는 접근이 일반적이었습니다.
컬럼 스토어 구조상 인덱스 없이도 처리되는 경우가 많고, 인덱스는 메모리와 쓰기 비용을 유발합니다. 남발할 대상이 아닙니다.
그렇다고 "HANA에는 인덱스가 필요 없다"는 말은 과장입니다. 대용량 테이블에서 선택도 높은 조건으로 소량을 뽑는 패턴에는 여전히 도움이 됩니다. 다만 인덱스 추가는 마지막 수단이고, 그 전에 쿼리와 조건을 먼저 손봐야 합니다. 추가 여부는 Basis·DBA와 협의하세요.
행 수를 줄이는 다른 방법도 있습니다.
SELECT SINGLE은 전체 키를 지정했을 때 1건이 보장됩니다. 키 일부만 주면 "조건에 맞는 것 중 아무거나 1건"이 오므로, 어떤 행이 올지 정해지지 않습니다. 정렬 기준이 필요하면 ORDER BY ... UP TO 1 ROWS를 쓰세요.
CHECK·DELETE로 내부 테이블을 정리하는 코드는 대부분 WHERE절로 옮길 수 있습니다.다음 ③편에서는 행이 아니라 열, 즉 전송량 줄이기를 다룹니다.
Disclaimer — 이 포스트는 AI(Claude)를 활용하여 작성된 초안을 바탕으로 검수 및 보완하여 작성되었습니다. 내용 중 오류나 오타가 있다면 댓글로 알려주시면 감사하겠습니다.