1. 인덱스에 대한 고찰

Spring boot quartz library를 사용하여 돌리는 Batch파일에 문제가 문제가 발생하였다.

결론부터 말하자면 서비스에 대한 수정을 요구한다.

 

해당 서비스를 수정하며 Select Query문을 보게 되었고, Plan을 돌려본 결과 2가지 문제에 대해 생각했다.

 

1년이 지난 회원을 계산하여 휴면계정으로 전환하는 배치였는데, 최근접속일시를 기준으로 접속여부를 판단했다.

중요한 부분은 최근접속일시가 null인 경우가 포함이 되어있다는 것과, varchar타입으로 되어 있다보니 Date타입으로 형변환을 하다보니 Index를 타지를 못하는 경우다.

 

1. 기존 Query에 대한 튜닝

Index를 태우기 위해서는 컬럼에 대한 가공은 해서는 안된다. 예를 들어 SUBSTRING을 사용한다는 경우 말이다.

지금 케이스의 경우 Date타입 형변환의 문제로 발생하였다. 따라서 컬럼을 계산이 다 진행된 타입과 비교하는 방식으로 진행하였다.

ex)

TO_DATE(TO_CHAR(SYSDATE,'YYYYMMDD'),'YYYYMMDD') - TO_DATE(SUBSTR(LATELY_CNCT_DTTM,1,8),'YYYYMMDD') >= '365'

변환

WHERE LATELY_CNCT_DTTM >= TO_CHAR(SYSDATE - 365, 'YYYYMMDD') || '000000'

결국 Index도 존재하지 않았기에 Index의 범위를 어느정도로 할것인가에 대한 고민으로 이어졌다. 

Select절에서 *으로 조회할경우 전체 44000건 중에서 30건만 넘어도 Full table scan으로 이어졌다.

하지만 전체 컬럼(4건)을 Index로 만들시, Plan을 보았을때, 2만건 이상의 조회에도 Index를 타는 모습을 보여주었다.

따라서 해당 경우는

1) Select절에 포함되는 컬럼은 2건

2) 인덱스를 경우하는 Table Access시 효율 저하

3) 주기적으로 실행되는 Batch Job

4) 3건의 Index존재와 이후 접속일자를 기준으로 조회하는 프로그램이 있기에 확장성 유무가 큼

이라는 조건으로 해당 Query에서 사용하는 컬럼 전체를 Index로 만들기로 결정하였다.

 

항상 Query를 짜거나 설계를 할시 컬럼가공, 제약조건이 존재한다면 무조건 넣어주는 습관을 들일 필요성이 있는것 같다.