실무에서 SQL튜닝을 처음 해본 후기

최근에는 SQL 튜닝 강의를 줄창 듣는 중이다. 지금 수행하고 있는 프로젝트에서 쿼리를 사용할 일도 많다. 지하철을 오가면서 강의를 주로 보는데 그러다보니 실제 쿼리에 적용해보는 일은 하지 못해서 아쉬움이 있었다. 그 아쉬움을 실무에서 풀어야지 하고 상상만 하고 있었다. 기회는 오래지 않아서 왔다. 현재 개발을 맡은 화면에서 데이터를 불러오는데 걸리는 시간이 생각보다 오래걸렸다. 해당 화면을 위해서 마트성 테이블을 구성하기도 하였으나 실시간으로 바뀔 수 있는 다른 테이블과 조인을 해야만 하는 상황이 있어서 마트만 구성을 할 수 없었으며 여러가지 조인 단계로 쿼리가 무척 길어졌다. 그에 비례하듯이 쿼리의 속도도 무척 느려졌다. 나는 강의에서 배운 것을 적용해봐야지 하며 기초적인 단계를 밟았다.

 

가장 먼저 한 것은 쿼리 실행 계획을 조회하는 것이었다. 강의의 내용은 오라클을 중심으로 이루어져 있었고 내가 지금 수행하고 있는 프로젝트의 데이터베이스는 티베로였으나 큰 차이는 없었다. 티베로는 오라클을 거의 베끼다시피 만들어져 있었기에 문법이나 제공 기능에도 차이는 없었다. 티베로 스튜디오에는 실행 계획을 조회하는 버튼이 친절하게 달려있기도 했다. 실행 계획을 보니 두 군데의 서브 쿼리에서 FULL TABLE SCAN이 이루어지고 있었고 비용이 많이 소모되고 있었다.

 

하나의 서브쿼리는 WHERE절에서 사용되고 있는 조건이 인덱싱이 되어 있지 않아서 FULL SCAN이 이루어지고 있는 것으로 보였고 이에 해당 테이블의 해당 컬럼에 인덱스를 추가하였다. 추가하고보니 확실히 비용이 줄어든 것을 확인할 수 있었다. 다른 하나의 서브쿼리에는 WHERE 조건을 넣을 수 있음에도 불구하고 넣지 않아서 FULL SCAN이 이루어지고 있었다. 조건을 추가하여 실행하니 역시 비용이 확연히 준 것을 확인할 수 있었다. 회사에 PC가 있고 비용이 어땠는지 확실히 기억하는 것은 아니기에 몇배로 줄었다고 하기는 어려운 부분이 있지만 체감상 2초 걸리던 작업이 0.2초로 줄어든 정도로 속도가 빨라졌다. 앞으로 그 화면에서 쿼리 때문에 속도가 나오지 않는 일은 없을 듯하다.

 

새로운 걸 배우고 그걸 적용해서 더 좋은 것을 만들어간다는 것은 개발자로 무척 즐거운 일이다. 앞으로 이런 즐거움이 더 있을 수 있도록 배우고 나아가고 싶다.