[주니어 백엔드 개발자가 반드시 알아야 할 실무 지식] 3장. 성능을 좌우하는 DB 설계와 쿼리

1. DB는 성능의 핵심

• 느린 쿼리의 주범: "풀 스캔" → 모든 행을 다 뒤지는 비효율적인 조회
• 성능 문제의 상당수가 DB 설계 미숙이나 잘못된 쿼리에서 발생

---

2. 조회 트래픽을 고려한 인덱스 설계

🔎 인덱스 기본

• 전문 검색 인덱스: 텍스트 검색에 특화된 인덱스 (예: Full-Text Index)
• 단일 인덱스: 하나의 칼럼 기준 인덱스
• 복합 인덱스: 여러 칼럼을 조합한 인덱스 (WHERE 절에 자주 함께 쓰이는 칼럼들)

🎯 인덱스 설계 팁

• 선택도 높은 칼럼 우선: 중복 적은 값일수록 인덱스 효과 큼
• 커버링 인덱스 활용: 쿼리가 인덱스만으로 처리되도록 설계 (SELECT 대상이 인덱스에 모두 포함)
• 인덱스는 꼭 필요한 것만: 많다고 좋은 게 아님 → 쓰기 성능 저하

---

3. 조회 성능 개선 방법

전략설명

✅ 미리 집계	자주 계산되는 값을 미리 저장해두기
✅ 정규화 vs 비정규화	조회 성능이 중요할 땐 비정규화 고려
✅ 동시성 문제 고려	성능 튜닝으로 인해 데이터 꼬이지 않도록 주의
✅ ID 기반 목록 조회	OFFSET보다 WHERE id < ? 방식이 성능 더 좋음
✅ 시간 기준 범위 제한	오래된 로그, 데이터는 조회에서 제외하도록 제한
✅ 전체 개수 세지 않기	COUNT(*)는 느릴 수 있음 → 가능하면 제거
✅ 평소 조회 패턴 파악	이상 징후(갑자기 느려짐 등)를 빨리 캐치 가능
✅ 오래된 데이터 분리	이력 데이터는 별도 테이블/DB로 이동
✅ DB 단편화 최적화	VACUUM, OPTIMIZE TABLE 등으로 정리
✅ DB 장비 확장	하드웨어로 해결할 수도 있음 (RAM, SSD 등)
✅ 캐시 서버 도입	Redis, Memcached 등으로 조회 부하 분산

 

---

4. 주의 사항

항목설명

⛔ 쿼리 타임아웃	오래 걸리는 쿼리는 서비스 장애의 원인
⛔ 복제 DB에서 쓰기 금지	상태 변경(결제 등)은 마스터 DB에서만 처리
⛔ 배치 쿼리 신중하게	대량 처리 작업은 성능 저하를 유발할 수 있음
⛔ 칼럼 타입 불일치 조인 주의	INT vs VARCHAR 조인은 성능 매우 안 좋음
⛔ 테이블 구조 변경은 신중히	서비스 중 변경은 위험도 큼
⛔ DB 연결 수 제한	너무 많은 연결은 서버 과부하로 이어짐

 

---

5. 실패와 트랜잭션 고려하기

• DB 작업 중 실패 가능성 항상 염두
• 트랜잭션 처리에서 예외 상황 고려해야 안전 (롤백, 중복 처리 방지 등)