슬로우 쿼리 분석, EXPLAIN 전에 할 일

DB(데이터베이스) 운영 화면을 처음 보는 사람이라면 “슬로우 쿼리(slow query)가 늘어나고 있다”는 알림만 떠도 어디부터 봐야 할지 막막해질 수 있습니다. 검색하면 보통 “EXPLAIN부터 보세요”라는 답이 먼저 나옵니다. 그런데 EXPLAIN을 보기 전에 먼저 해야 할 일이 있습니다. 바로 그 쿼리가 언제, 어느 인스턴스에서 몰렸는지부터 좁혀 보는 것입니다.

‍

슬로우 쿼리가 뭔가요?

슬로우 쿼리는 쉽게 말해 기준 시간보다 오래 걸린 SQL(Structured Query Language) 실행 기록입니다. MySQL·PostgreSQL 같은 관계형 DB에는 일정 시간 이상 걸린 쿼리만 따로 남기는 기능이 있고, 이를 슬로우 쿼리 로그(slow query log)라고 부릅니다. MySQL은 기본 기준 시간이 10초로 설정돼 있으며, 실제 운영 환경에서는 1~3초 수준으로 조정해 사용하는 경우가 많습니다.

쿼리가 기준 시간을 넘는 이유는 다양합니다. 인덱스가 없는 컬럼을 조회했거나, 조인 대상 테이블 크기가 급격히 커졌거나, 특정 시간대에 같은 테이블로 요청이 몰렸을 수도 있습니다. 예를 들어 평소에는 0.2초 안에 끝나던 주문 조회 SQL이, 광고 트래픽이 몰리는 시간대에만 5초 이상 걸리는 상황도 흔하게 발생합니다.

‍

왜 신경 써야 하나요?

슬로우 쿼리는 한 건만 보면 “조금 느린 SQL”처럼 보일 수 있습니다. 하지만 같은 쿼리가 반복해서 실행되기 시작하면 이야기가 달라집니다. 5초 걸리는 쿼리가 시간당 100번 실행되면, 그 쿼리 하나만으로도 DB 자원을 8분 넘게 점유하게 됩니다. 그 사이 다른 요청들도 대기열에 쌓이기 시작하고, 결국 애플리케이션 전체 응답 속도까지 느려질 수 있습니다.

여기서 중요한 건 “느린 쿼리 한 건”과 “전체적으로 느려진 DB”는 같은 문제가 아니라는 점입니다. 알림에 찍힌 SQL 하나는 단순한 증상일 수 있습니다. 실제 원인은 특정 시간대에 요청이 몰렸거나, 특정 인스턴스에서만 부하가 집중된 상황일 수도 있습니다.

‍

EXPLAIN을 바로 보면 헷갈리는 이유

슬로우 쿼리 로그에서 SQL 하나를 확인한 뒤 곧바로 EXPLAIN(쿼리 실행 계획을 보여 주는 명령)부터 실행하는 경우가 많지만, 입문자에게는 오히려 헷갈릴 수 있습니다.

• 그 쿼리가 정말 누적 부하의 원인인지 알 수 없습니다. 한 건만 우연히 느렸을 수도 있습니다
• 언제 느려졌는지 모르면 같은 쿼리도 시간대마다 실행 계획이 달라질 수 있습니다
• 여러 인스턴스 중 어디에서 느렸는지 모르면, 잘못된 인스턴스의 통계를 보고 엉뚱한 인덱스를 걸 수도 있습니다

쉽게 말하면 EXPLAIN은 “어느 정도 범위를 좁힌 뒤, 특정 SQL을 자세히 들여다보는 도구”에 가깝습니다. 아직 범위를 좁히지 않은 상태에서 실행 계획부터 펼치면 정보만 많아지고, 오히려 흐름을 놓치기 쉽습니다.

그래서 슬로우 쿼리를 처음 분석할 때는 EXPLAIN보다 먼저 “언제, 어느 인스턴스에서 느려졌는지”부터 좁혀 보는 흐름이 중요합니다. 이 과정을 건너뛰면 튜닝을 마친 뒤에도 같은 알림이 반복해서 발생할 수 있습니다.

‍

와탭 DB 분석 메뉴 — 5분 워크플로

슬로우 쿼리는 보통 시간대 → 인스턴스 → SQL Elapse Map 순서로 좁혀 봅니다.

1단계: 대시보드에서 시간대 좁히기

대시보드에서는 먼저 “언제부터 느려졌는가”를 봅니다. 응답 시간이나 Active Session 그래프가 평소보다 튀기 시작한 시점을 기준으로, 문제 구간을 먼저 좁혀 보는 단계입니다.

여기서 흔히 하는 실수는 알림이 뜬 시각만 보는 것입니다. 실제 부하는 알림보다 먼저 쌓이기 시작한 경우가 많습니다. 그래서 알림 시각보다 30분~1시간 정도 앞 구간까지 함께 보는 편이 안전합니다.

2단계: 인스턴스 좁히기와 SQL 식별

DB는 보통 한 대만 두고 운영하지 않습니다. 읽기·쓰기 역할을 나눈 복제 구조이거나, 서비스별로 인스턴스를 따로 두는 경우가 많습니다. 같은 SQL이라도 어느 인스턴스에서 실행됐는지에 따라 부하 양상이 달라질 수 있기 때문에, 먼저 슬로우 쿼리가 어느 인스턴스에 몰렸는지 확인합니다.

와탭 멀티 인스턴스 모니터링 화면에서는 인스턴스 비교와 SQL 식별을 한 화면에서 볼 수 있습니다.

• Long Active Session Count 막대 그래프로 인스턴스별 분포를 비교합니다. < 3초, < 10초, < 15초, ≥ 15초 구간별로 어느 서버에 긴 세션이 몰리는지 빠르게 확인할 수 있습니다.
• SQL Elapse Map에서 부하가 튄 시간 구간을 마우스로 드래그하면, 그 구간에 길게 돌고 있던 SQL 목록이 Query List 팝업이 열리며 SQL을 바로 확인할 수 있습니다.
• 보통 누적 시간(runtime)이 긴 순서로 정렬되는데, 한 건짜리 5초 쿼리보다 100번 실행된 0.5초 쿼리가 위로 올라오는 경우도 있다고 합니다. 여기서 처음으로 "이 SQL을 들여다봐야겠다"는 후보가 좁혀집니다.

SQL Elapse Map은 5초 간격으로 수집된 액티브 세션을 기반으로 보여 주는 화면입니다. DB 엔진이 직접 기록한 슬로우 쿼리 로그 자체를 보고 싶다면 대시보드 > 슬로우 쿼리 메뉴를 별도로 활용하면 됩니다. 두 화면은 보는 데이터 출처가 다르기 때문에, 같은 시간대라도 목록이 조금씩 달라질 수 있습니다.

3단계: EXPLAIN과 튜닝

이제 EXPLAIN으로 실행 계획을 확인합니다. 식별한 SQL이 인덱스를 제대로 사용하는지, 조인은 어떤 방식으로 수행되는지, 예상보다 많은 행을 스캔하고 있지는 않은지 확인하면서 튜닝 방향을 잡습니다.

처음부터 EXPLAIN 결과를 모두 이해할 필요는 없습니다. 예를 들어 인덱스를 타지 않고 전체 테이블을 읽는 type: ALL 같은 항목만 보여도 중요한 단서가 됩니다. 더 복잡한 실행 계획은 DBA(Database Administrator, DB 관리자)나 시니어 개발자와 함께 보는 경우도 많습니다.

‍

마치며

슬로우 쿼리를 발견했다고 해서 바로 EXPLAIN부터 볼 필요는 없습니다. 먼저 “언제부터 느려졌는지”, “어느 인스턴스에 부하가 몰렸는지”부터 좁혀 보는 흐름이 더 중요합니다.

와탭 DB 모니터링에서는 대시보드에서 시간대를 확인하고, 멀티 인스턴스 모니터링의 SQL Elapse Map과 Query List로 문제 SQL을 식별한 뒤, 마지막에 EXPLAIN으로 실행 계획을 확인하는 흐름으로 이어집니다.

와탭 DB 모니터링이 처음이라면 공식 문서의 제품별 시작하기 페이지(예: PostgreSQL 모니터링 안내, MySQL 시작하기)부터 한번 둘러보는 것도 좋습니다. 직접 화면을 보며 따라가 보고 싶다면 와탭 DB 모니터링 무료 체험으로 시작해 볼 수 있습니다.

‍

더 읽을거리

• 와탭 DB 모니터링 제품 페이지
• 와탭 PostgreSQL 모니터링 안내
• 와탭 MySQL 시작하기
• MySQL 슬로우 쿼리 로그 공식 가이드
• PostgreSQL pg_stat_statements 공식 가이드