들어가며

개발/운영 중인 시스템이 점점 커지기도 하고, 사용자들의 눈높이도 높아져서 빠른 속도에 대한 니즈가 계속해서 증가하고 있다. 작년에 프로젝트를 진행하며 속도를 개선할 수 있는 다양한 방법(어플리케이션 아키텍처 변경, 프로세스 간소화, SQL 튜닝)을 고민하고 적용했다. 그리고 그 중 가장 많은 비중을 차지한 것이 SQL 튜닝을 통한 속도 개선이었다.

나름 문제가 되는 쿼리를 추출하고 개선을 진행하여 효과를 보았지만, SQL 영역에서 스스로 많은 부족함을 느꼈다. 개발자로서 백엔드 개발 영역은 열심히 공부했지만, DB와 SQL은 사용할 수 있을 정도로만 했었다. 늦은 감이 있긴 하지만, 지금에서라도 다시 공부해서 기본기를 다질 것이다.

학습 서적

예전에 공부하려고 구매했던 《실전사례로 살펴보는 SQL 튜닝 비법》로 공부를 할 예정이다. 조금 오래된 책이긴 하지만, 기본기를 다지기에는 큰 무리가 없다는 판단이다. 예전에도 공부를 했었던 흔적이 있긴한데, 이번에는 블로그에도 기록을 해서 잘 습득해야겠다.

1장.SQL 튜닝개요

SQL 튜닝이란?

SQL 튜닝은, 최소한의 CPU, I/O, 메모리를 사용하여 최대한 빠른 시간 내에 원하는 데이터 작업을 수행하도록 만드는 것을 말한다. 바꾸어 말하면, CPU, I/O, 메모리 등의 자원을 불필요하게 사용하지 않도록 하는 작업을 의미한다.

SQL 튜닝은 왜 필요한가?

문제는 개발자들 대부분이 개발 환경에서의 실행 시간만 확인하고 본인의 SQL에 문제가 없다고 판단해 버리는 데에 있다.

SQL의 수행 속도는 환경에 의존적인 값으로, 이 값은 환경이 변하면 함께 변한다. 따라서 개발 환경에서 작성한 SQL이 운영 환경에서는 어떤 계획을 세워 어떠한 경로로 수행될 지를 살피는 과정이 반드시 수반되어야 한다.

개발 일정이 촉박하다는 핑계로 한 건의 개발이 완료되면, 바로 다음 개발 건으로 넘어갈 때가 많았다. 운영 환경에 반영된 것들에 대해서 기능상 문제 뿐만 아니라, 속도 측면에서도 다양하게 검토가 필요하다. 더 좋은 방법은 속도를 측정하는 모니터링 툴을 통해서 느린 트랜젝션들을 뽑아내는 것이다.

SQL 튜닝은 언제 하는가?

SQL 튜닝은 분석 및 설계 단계를 시작으로 개발 및 구현 단계는 물론, 운영 단계에도 지속적으로 해야 하는 작업이다.

SQL 튜닝은 어떻게 하는가?

수집된 SQL 수행 이력 정보가 분석을 위한 정보로 가치가 있으므로 이를 활용한다.

일반적으로 튜너들은 개발자들에 비해 제한된 정보만으로 SQL을 검토할 가능성이 높다. 따라서 해당 업무에 대해 보다 구체적인 정보를 알고 개발자 차원에서의 검토가 충분히 이루어져야 한다.

SQL 튜닝 유형

저자가 오랫동안 분석한 SQL 문제 유형 중 52%가 인덱스 관련 문제였고, 20%가 JOIN 관련 문제였다. 물론 비즈니스 프로세스 자체를 개선하는 효과도 있겠지만, 실제로 문제 유형의 대다수가 DB를 제대로 이해하지 못하여 발생한 문제였다. 인덱스와 JOIN 영역에서 세부 유형은 아래와 같다.

현재 내가 개발/운영하는 시스템의 경우 인덱스 자체가 없는 경우는 많지 않다. 인덱스가 있음에도 인덱스가 제대로 활용되지 않는 케이스가 있고, 이를 중점적으로 검토하면 문제를 빠르게 개선할 수 있을 것 같다.

JOIN의 경우에는 고민해야할 문제들이 조금 더 많다. 조인 방식이나 순서에 따른 속도 차이를 명확히는 몰라서 이번 기회에 제대로 익히고 문제들을 개선해볼 생각이다.