4편. DB 성능 모니터링 집중 분석 + 실제로 효과가 컸던 SQL 튜닝 사례

 

DB 성능 모니터링 집중 분석

🟦 4편. DB 성능 모니터링 집중 분석 + 실제로 효과가 컸던 SQL 튜닝 사례

백엔드 서비스가 커질수록 병목의 대부분은 결국 DB에서 발생한다.
Spring, JVM, 네트워크 튜닝도 중요하지만, 운영 경험상 가장 즉각적이고 가장 큰 성능 개선 효과를 주는 지점은 바로 DB 성능 모니터링 → SQL 튜닝이다.

이번 편에서는 실제 운영 환경에서 사용하는 DB 모니터링 방식과
성능을 몇 배까지 끌어올린 실전 SQL 튜닝 사례를 정리한다.

---

■ 1) DB 성능 모니터링의 핵심 관점

DB 성능은 아래 4가지 지표를 중심으로 추적하면 대부분 문제를 찾을 수 있다.

---

✔ 1) 느린 쿼리(Slow Query) 모니터링

실제 운영에서 가장 중요한 지표

• 평균 쿼리 응답시간
• 95/99 percentile
• 초당 쿼리 건수(QPS)

MySQL 예:

• slow query log 활성화
• pt-query-digest로 패턴 분석
• AWS RDS → Performance Insights

Oracle/Sybase 예:

• AWR / ASH / Statspack
• sp_showplan / monitoring view
• BI Matrix 혹은 전사 SQL 모니터링 도구

---

✔ 2) 락(Lock) & 락 경합(Lock Contention)

DB 고질적 병목 1순위.

자주 보는 지표:

• row lock, table lock
• lock wait time
• deadlock 발생 여부
• 특정 트랜잭션의 대기열 길이

특히 금융권에서는 락 하나 때문에 전체 배치가 몇 시간 지연되기도 한다.

---

✔ 3) 인덱스 사용 여부 & 풀스캔 탐지

인덱스가 있어도 조건이 아래 중 하나면 인덱스를 무용지물로 만든다.

• LIKE ‘%keyword’
• 계산식 포함: WHERE DATE(created_at) = ...
• 범위 조건 남발
• OR 조건 다수
• 인덱스 컬럼 불일치(스키마-쿼리 mismatch)

실제 운영에서는 실행계획(EXPLAIN) 의 변화만 봐도 대부분 문제를 찾는다.

---

✔ 4) 세션/커넥션 모니터링

• connection pool 사이즈 부족
• idle session 누적
• max_connections 초과
• 장시간 실행되는 오래된 세션(=좀비 세션)

Spring Boot에서 HikariCP 로그만 봐도 상당 부분 파악할 수 있다.

---

■ 2) 실전 환경에서 사용하는 모니터링 도구

🟦 Spring 기반 서비스 내부 모니터링

• Actuator + Micrometer
• Prometheus + Grafana (쿼리 지연/connection pool 지표 시각화)
• P6Spy, datasource proxy

🟧 DB 자체 모니터링

• MySQL Performance Schema
• Oracle AWR/ASH
• Sybase monitor view
• PostgreSQL pg_stat_statements

🟩 로그/시스템 레벨

• CloudWatch / RDS Insights
• ELK Stack
• pin-point, 스카우터

운영이 안정된 팀일수록 위 도구들을 동시에 활용한다.

---

■ 3) 실전에서 ‘효과가 엄청 컸던’ SQL 튜닝 사례

운영 환경에서 실제로 성능이 크게 개선되었던 대표 사례들만 정리했다.

---

🟦 사례 1) OR → UNION ALL로 변환 (2000ms → 80ms)

문제 쿼리:

SELECT * FROM orders
WHERE status = 'PAID'
   OR status = 'READY'
   OR status = 'COMPLETE';

문제점:

• OR 조건이 많아지면 인덱스를 못 타거나 index merge가 발생
• leading column 하나가 성능을 좌우하는데 OR가 이를 파괴

개선안:

SELECT * FROM orders WHERE status = 'PAID'
UNION ALL
SELECT * FROM orders WHERE status = 'READY'
UNION ALL
SELECT * FROM orders WHERE status = 'COMPLETE';

결과:

• 인덱스를 세 번 잘 타는 것으로 분할
• 응답시간 2000ms → 80ms (약 25배 개선)

---

🟦 사례 2) COUNT(*) 대량 집계 → 카운트 전용 테이블로 변경 (배치 3시간 → 20분)

문제:

SELECT COUNT(*) FROM transaction_log WHERE created_at BETWEEN ? AND ?;

transaction_log가 수천만 건 이상으로 증가하면서 집계 배치가 폭발.

개선:

• 매일 0시마다 summary table에 count만 저장
• 운영 쿼리는 summary table을 조회

결과:

• 배치 3시간 → 20분
• 애플리케이션에서 CPU 사용량 70% 감소

---

🟦 사례 3) JOIN 4단계 → 서브쿼리 캐싱 + 인덱스 정렬 (800ms → 40ms)

문제:

• A → B → C → D 조인을 통해 단일 상품 정보를 조회
• C 테이블에서 full scan 발생

원인:

• C 테이블의 join key 컬럼에 인덱스 없었음
• order by 때문에 filesort 발생

개선:

• 필요한 join key에 composite index 생성
• 정렬 조건을 인덱스 순서와 일치하도록 변경
• 일부 서브쿼리는 Redis 캐싱

결과:

• 800ms → 40ms (20배 단축)

---

🟦 사례 4) LIKE ‘%keyword’ → 역인덱스 + 검색 전용 테이블 (1500ms → 50ms)

문제:

WHERE name LIKE '%은행%'

개선:

• 역인덱스 or N-gram 인덱스 적용
• 검색 전용 테이블 생성
• 또는 ElasticSearch로 분리

결과:

• 1500ms → 50ms
• 검색 API 30배 향상

---

🟦 사례 5) 무거운 정렬 제거 (order by → limit 최적화) 1200ms → 60ms

기존:

SELECT * FROM account_history
WHERE user_id = ?
ORDER BY created_at DESC
LIMIT 20;

문제:

• created_at 인덱스가 없어 전체 정렬 발생

개선:

CREATE INDEX idx_history_user_created_at ON account_history(user_id, created_at DESC);

결과:

• 정렬 비용 제거
• 1200ms → 60ms

---

■ 4) Spring에서 SQL 튜닝 효과를 최대화하는 방식

✔ 1) 불필요한 Lazy 로딩 차단

@Query("select u from User u join fetch u.orders where u.id = :id")

✔ 2) DTO projection 적극 사용

엔티티 기반보다 전송 비용 30~80% 절감.

✔ 3) 대량 insert/update는 batch 옵션 필수

HikariCP + Hibernate batch 옵션 조합 효과 큼.

✔ 4) 읽기 전용 쿼리는 replica로 분리

읽기 부하가 많은 서비스에서는 무조건 해야 하는 구조.

---

■ 5) 마무리

이번 편에서는 실전 환경에서 바로 쓰는 DB 모니터링 지표와 도구,
그리고 실제 운영에서 효과가 컸던 SQL 튜닝 사례들을 소개했다.

핵심은 하나다.

DB는 “감”이 아니라 “지표 + 실행계획 + 패턴 분석”으로 튜닝해야 한다.

다음 편에서는 드디어:

“실전 운영 장애 사례 10선 + 장애 복구 플레이북”

을 다뤄 드릴게요.

🍃 Spring Boot 성능 튜닝 시리즈 (전 5편)

1. 1편 — 운영 서버에서 실제로 효과 본 방법
2. 2편 — Jackson 직렬화 튜닝: 숨은 CPU 병목 해결
3. 3편 — ThreadPool & Tomcat 튜닝: 트래픽 폭주 대응
4. 4편 — DB 성능 모니터링과 SQL 튜닝 사례 (현재 글)
5. 5편 — 운영 장애 사례 10선 + 장애 복구 플레이북