MySQL 슬로우 쿼리 로그 설정·분석｜안전한 30분 진단

MySQL 슬로우 쿼리 로그는 실제로 시간을 소비한 SQL을 찾는 도구입니다. 무작정 인덱스를 추가하면 쓰기 성능과 공간만 낭비할 수 있습니다. 짧은 관찰 구간의 반복 횟수와 누적 시간을 확인한 뒤 한 가지씩 수정해야 합니다.

기준 시간을 지나치게 낮추면 파일이 커지고 SQL의 검색어·이메일 등이 기록될 수 있습니다. 아래 순서는 설정값 보관부터 분석과 원복까지 포함합니다.

10초 요약

• 현재 설정과 디스크 여유 공간을 먼저 기록합니다.
• 운영 트래픽이 포함되는 짧은 관찰 시간을 정합니다.
• 한 번 가장 느린 SQL보다 누적 시간이 큰 패턴을 우선합니다.
• EXPLAIN의 예상 행 수와 실제 호출 빈도를 함께 봅니다.
• 측정이 끝나면 로그를 끄고 기존 기준값과 보존 정책을 복구합니다.

슬로우 쿼리가 기록되는 조건

MySQL 공식 문서에 따르면 실행 시간이 long_query_time 이상이고 검사한 행 수가 min_examined_row_limit 이상인 문장이 기록 대상입니다. slow_query_log가 켜져 있어도 log_output이 NONE이면 출력되지 않습니다. 실행 시간은 CPU 시간만이 아니라 실제 경과 시간이라 서버 부하에 따라 같은 SQL도 기준을 넘을 수 있습니다.

1단계: 현재 값과 운영 조건 기록

SHOW VARIABLES WHERE Variable_name IN (
  'slow_query_log',
  'slow_query_log_file',
  'long_query_time',
  'min_examined_row_limit',
  'log_output'
);

출력 결과와 MySQL 버전, 측정 시작 시각, 평소 트래픽, 디스크 여유 공간을 적습니다. 관리형 DB는 파라미터 그룹과 로그 서비스 등 공급자 방식을 우선하세요. 복제가 있다면 어떤 노드를 측정하는지도 확인합니다.

2단계: 제한된 시간 동안 활성화

MySQL 8의 관련 변수는 동적으로 바꿀 수 있지만 권한과 환경에 따라 적용 방법이 다릅니다. 다음은 원래 값을 보관한 뒤 사용할 수 있는 예시이며, 숫자 1초가 모든 서비스의 정답은 아닙니다.

SET GLOBAL log_output = 'FILE';
SET GLOBAL long_query_time = 1.0;
SET GLOBAL slow_query_log = ON;

변경 직후 별도 연결에서 값을 다시 확인합니다. 10~30분처럼 종료 시각을 정하고 파일 크기와 디스크 쓰기를 관찰하세요. log_queries_not_using_indexes는 짧은 쿼리까지 대량 기록할 수 있으므로 처음부터 켜지 않습니다.

로그에는 SQL 리터럴과 사용자 정보가 들어갑니다. 권한을 최소화하고 외부 공유 전 값을 마스킹하며 보존 정책에 따라 삭제·회전하세요.

3단계: 느린 한 건보다 누적 부하 찾기

로그 순서가 실행 시작 순서와 같다고 가정하면 안 됩니다. MySQL은 문장이 끝나고 잠금이 해제된 뒤 로그에 씁니다. 각 항목의 Query_time, Lock_time, Rows_sent, Rows_examined와 반복 횟수를 묶어 판단하세요.

mysqldumpslow나 pt-query-digest로 비슷한 SQL을 묶을 수 있습니다. MySQL 8의 sys.statement_analysis도 실행 횟수, 전체·평균·최대 지연과 검사 행을 제공합니다. 최고 시간보다 전체 지연 × 사용자 영향이 큰 패턴을 우선하세요.

SELECT query, exec_count, total_latency,
       avg_latency, rows_examined, full_scan
FROM sys.statement_analysis
LIMIT 20;

4단계: EXPLAIN으로 실행 계획 확인

EXPLAIN은 옵티마이저가 예상한 접근 순서, 인덱스와 행 수를 보여줍니다. type=ALL 하나만 보고 실패라고 단정하지 말고 테이블 크기, 반환 비율과 호출 횟수를 함께 보세요. 자세한 열 해석은 MySQL EXPLAIN 실행 계획 읽기에서 확인할 수 있습니다.

EXPLAIN
SELECT id, created_at
FROM orders
WHERE status = 'pending'
ORDER BY created_at DESC
LIMIT 50;

EXPLAIN ANALYZE는 예상값과 실제 행 수, 반복 횟수와 시간을 비교할 수 있지만 문장을 실제 실행합니다. 운영 환경의 무거운 SELECT나 데이터를 바꾸는 문장에 바로 사용하지 말고 복제된 테스트 데이터와 읽기 전용 조건에서 검증하세요.

5단계: 한 가지 수정 후 같은 조건으로 비교

• 필요한 열만 조회하고 불필요한 범위를 줄입니다.
• N+1 호출은 쿼리 결합이나 결과 캐시 가능성을 검토합니다.
• 인덱스는 WHERE·JOIN·정렬 조건과 선택도를 기준으로 설계합니다.
• 인덱스 추가 후 SELECT뿐 아니라 INSERT·UPDATE 지연과 크기를 확인합니다.
• 통계가 오래됐다면 운영 절차에 맞게 갱신 여부를 검토합니다.

워드프레스 요청에서 어떤 플러그인이 쿼리를 만들었는지 먼저 찾으려면 Query Monitor 느린 플러그인 진단을 함께 사용하세요. DB 쿼리가 아니라 전체 서버 응답이 느린 경우에는 TTFB 원인 구분 순서로 PHP·캐시·외부 API를 나눠 확인하는 편이 정확합니다.

점검 종료와 원복 기준

1. 관찰 종료 시각과 로그 파일 크기를 기록합니다.
2. SET GLOBAL slow_query_log = OFF;로 임시 기록을 종료합니다.
3. long_query_time, log_output 등 바꾼 값을 기존 설정으로 복구합니다.
4. 새 연결에서 설정값을 다시 조회해 원복을 확인합니다.
5. 분석용 사본의 접근 권한과 삭제 기한을 정합니다.
6. 수정 전후를 같은 트래픽 구간에서 비교합니다.

TIP

‘느린 쿼리 10개’보다 ‘전체 지연의 몇 퍼센트를 차지하는 패턴인지’를 기록하세요. 한 번 3초 걸린 관리 쿼리보다 매 요청마다 80ms씩 50번 실행되는 쿼리가 사용자 지연과 DB 부하를 더 크게 만들 수 있습니다.

자주 묻는 질문

long_query_time은 몇 초가 적당한가요?

모든 서버에 같은 정답은 없습니다. 평소 응답 목표와 트래픽을 기준으로 시작하고 로그 증가량을 보며 단계적으로 낮추세요. 처음부터 0초로 두면 거의 모든 문장이 기록될 수 있습니다.

인덱스를 사용하지 않는 쿼리는 모두 문제인가요?

아닙니다. 작은 테이블의 전체 스캔은 인덱스보다 효율적일 수 있습니다. 검사 행, 반환 비율, 호출 횟수와 누적 시간을 함께 판단해야 합니다.

공식 자료

• MySQL 8.4 Slow Query Log
• MySQL 8.4 EXPLAIN과 EXPLAIN ANALYZE
• MySQL sys.statement_analysis 뷰
• Percona pt-query-digest 문서

마무리

MySQL 슬로우 쿼리 분석의 핵심은 사용자 지연을 만드는 반복 패턴을 찾는 것입니다. 설정값과 종료 시각을 기록하고 누적 지연이 큰 SQL의 실행 계획과 호출 코드를 확인하세요. 한 가지 수정 후 읽기·쓰기 성능을 재측정하고 로그와 민감정보를 정리하면 운영 위험을 줄일 수 있습니다.

검증 기준 2026년 9월 2일 MySQL 공식 문서를 확인했습니다. 명령을 실행하기 전에 권한, 로그 출력 방식과 관리형 DB의 제공 기능을 확인하세요. 아래 값은 독자가 직접 기록하며 SJSBiz 운영 서버의 측정 결과가 아닙니다.

로그를 켜기 전에 디스크와 경로부터 확인한다

슬로우 쿼리 로그는 진단 자료를 만들지만 기록량이 많으면 저장 공간과 I/O에 부담을 줄 수 있습니다. 활성화 전에 현재 설정, 로그 출력 방식, 파일 경로, 남은 디스크 공간, 보관 기간과 회전 정책을 기록합니다. 관리형 데이터베이스에서는 파일에 직접 접근하지 못할 수 있으므로 제공업체의 로그 화면과 보관 정책을 우선 확인합니다.

MySQL Slow Query Log 공식 문서에 따르면 long_query_time과 조사 행 제한으로 기록 대상을 정할 수 있습니다. 처음부터 지나치게 낮게 설정하면 정상 쿼리까지 대량 기록될 수 있습니다. log_queries_not_using_indexes도 작은 테이블의 정상 전체 읽기까지 많이 기록할 수 있으므로 무조건 켜지 않습니다.

진단 종료 체크리스트

• 변경 전 설정값과 원복 명령을 기록했습니다.
• 로그 파일 크기와 남은 디스크 공간을 확인했습니다.
• 호스트명, 계정, 쿼리 값 등 민감정보를 공유 화면에서 가렸습니다.
• 빈도가 높은 쿼리와 일회성 지연을 분리했습니다.
• 수정 전후를 같은 조건으로 비교하고 반환 결과가 같은지 확인했습니다.
• 관찰이 끝난 뒤 임시 설정을 원복하고 로그 회전 상태를 확인했습니다.

관련 진단은 WordPress Query Monitor와 WordPress TTFB의 최종 주소로 직접 연결합니다.

문서 확인·수정 이력: 2026-09-02 — 로그 용량·민감정보 주의, 종료·원복 체크리스트와 공식 근거를 추가했습니다.