SQL 최적화, Locking vs. DML

… 데이터 액세스 양의 변화는 아래와 같은 요소들에 의해 큰 변화를 받는다.

  • 인덱스 사용 유무
  • 조인 방식
  • 클러스터 팩터
  • SQL 문

이와 같은 요소에 의해 10건을 추출하는 SQL은 100만 건의 데이터를 액세스한 후 10건의 데이터 만을 결과로 추출할 수 있고 진정으로 10건의 데이터만을 액세스하여 결과를 추출할 수도 있다.
결국 SQL 최적화는 보이지는 않지만 결과를 추출하기 위해 불필요한 데이터를 액세스하는 과정을 제거하는 일련의 활동이라고 할 수 있다…

권순용 님의 글을 읽다가 문득 어제 일이 생각이 났다.

Function Monitoring 쪽 SQL을 check 하다가 where 조건을 하나 더 추가했더니 소요시간이 99%나 줄었다.
데이터 양 자체는 별로 많지 않았지만 locking으로 인한 ‘경합’이 문제였다. 마침 해당 테이블에 PID란 칼럼이 있어서 이를 조건으로 추가했더니 – 즉 각 프로세스가 자기 PID에 해당하는 데이터만 액세스 – 더 많은 INSERT / UPDATE가 발생했지만 statement 당 소요시간은 99%나 줄었다. (예를 들어 총 10개의 DML을 5개의 프로세스가 경합하면서 작업하는 것보다 각 프로세스당 10개씩 총 50개의 DML을 실행시켜 버리는 것이 훨씬 싸게 먹힌다)

INSERT / UPDATE 횟수를 줄이는 것보다 경합이 있을 경우 이를 피하는 것이 더 현명하다.
발상의 전환이 필요하다고 할까.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">