SQL 튜닝 대한 접근 방법

개요

만약 SQL 튜닝을 진행한다면, 어떤 방식으로 접근하고 계신가요? 때로는 업무를 하다가 왜 이렇게 해야 하는지, 그 이유를 잊을 때가 있습니다. 튜닝을 위한 튜닝을 하고 있는지 한 번 다시 고민해 보시는 것도 좋을 것 같습니다.

SQL 튜닝을 위한 접근방법

실행 중인 SQL 문을 보면 무엇을 의도로 작성되었는지 명확하게 드러납니다. 매우 긴 SQL 문을 보면 먼저 실행 계획(Plan)을 확인하고 일반적으로 예상된 행 수와 실제로 발생한 행 수를 비교하여 왜 이러한 동작을 하는지 원인을 찾아냅니다. 옵티마이저가 잘못된 계획을 수립하거나 계산 결과가 틀린 경우 대부분 통계 정보와 실제 데이터 간의 차이에서 발생합니다.

SQL이 작성되어 실행되면, SQL 튜너는 SQL의 의도보다는 오라클 데이터베이스 엔진 내부의 동작 방식을 분석하여 튜닝합니다. 따라서 SQL 튜너의 능력은 옵티마이저를 얼마나 잘 이해하고 얼마나 많은 튜닝 경험을 쌓았는지에 비례하여 발전합니다.

• SQL 튜닝을 위한 일반적인 접근
  • 힌트를 사용하여 최적의 실행 계획을 고정합니다.
  • 해당 SQL에 적합한 인덱스를 만들어 데이터 액세스 방식을 개선합니다.
  • 테이블을 파티션화하여 데이터 액세스 범위를 줄입니다.
  • 조건을 추가하여 데이터 액세스 범위를 줄입니다.

일반적으로 우리는 힌트를 사용하여 최상의 계획이 수립되도록 하거나 테이블 구조를 변경하여 데이터 액세스 범위를 줄이는 방법을 주로 사용했습니다. 저만 그런가요? (이러한 방법이 잘못된 것이 아니라, 튜닝의 한 방법일 뿐이며 실력과 경험이 필요한 작업입니다. ) 그리고 우리는 “작성된 SQL은 의도에 맞게 작성되었다”는 전제로 SQL 튜닝을 시작하고 있는것 같습니다.

SQL 작성의도를 물어본적이 있나요?

어느 SQL이 엄청 많이 실행되며 DB부하에 많은 부하를 차지하고 있었습니다. 아래 SQL구문을 보니 “고객별로 마지막 트랜잭션 시간을 확인하고 싶다” 라는 작성의도가 보였습니다.

select account_id, max(tnx_ts) last_ts
  from customer_trans
group by account_id 
order by 1

이 SQL은 단순해 보이지만, 일반적인 접근 방법으로도 충분히 성능을 개선할 수 있습니다.

하지만 또 다른 접근 방법이 필요합니다. 작성자에게 직접 물어보는 방법입니다.

“이 SQL은 어떤 목적으로 작성한건가요?” 내가 생각하기에는.. 이런의도인것 같은데..
개발자 왈~ “아 최근에 활동한 고객 목록을 확인하고 싶어요” 라는 말을 했습니다.

작성 의도를 듣고 나니 다양한 아이디어가 떠올랐습니다. customer_trans이라는 history 테이블을 조회하는것보다, customer_account 테이블에 있는last_login_time 컬럼을 활용하면 더 효과적일 것 같습니다.

select account_id, last_login_time
  from customer_account
order by 1

개발자가 바보도 아니고 너무 빈약한 사례인것 같죠?

SQL 튜너가 접근하기 어려운 영역은 실제 업무와 관련된 데이터 파악이라고 생각합니다. 당연히 작업을 담당하는 업무자는 해당 업무에 능숙할 것이며, 이러한 사례가 발생하는 경우는 매우 드물 것입니다. 그렇지만 작업자도 완벽하지 않기 때문에 때로는 업무 관점에서 다른 방법이 없는지 물어볼 수 있을 것 같습니다.

마무리

어느 날, 갑자기 SQL 문장을 보면서 업무를 진행하고 있다는 생각이 들었습니다. SQL를 작성한 사람에게 질문을 하고, SQL 자체를 개선하거나 더 나은 SQL을 작성하는 방법을 찾는다면 성능을 향상시킬 수 있다고 느꼈습니다.
개발자에게 좀더 친밀감을 갖고 접근하는 것도 중요하다고 생각합니다.