“DB 인덱스는 책의 목차와 같다”
필요한 데이터를 빠르게 찾게 해주는 장치가 인덱스다.
그런데, 모든 컬럼에 인덱스를 걸면 오히려 성능이 나빠질 수 있다.
그 핵심 이유가 바로 카디널리티, 선택도, 활용도다.
"서로 다른 값의 개수"
| 수준 | 의미 | 예시 |
|---|---|---|
| 높음 (High) | 값이 대부분 다름 | 주민번호, 이메일 |
| 중간 | 적당히 다양한 값 존재 | 나이, 생년월일 |
| 낮음 (Low) | 값 종류가 거의 없음 | 성별, Boolean |
"조건이 전체 데이터에서 얼마나 좁은 범위를 선택하는가"
선택도 = 조건에 맞는 행 수 / 전체 행 수
"인덱스가 실제 쿼리 실행에서 얼마나 자주, 잘 사용되는가"
| 개념 | 의미 | 인덱스 설계 시 고려 |
|---|---|---|
| 카디널리티 | 서로 다른 값의 개수 | 높을수록 좋음 |
| 선택도 | 조건이 전체에서 좁게 걸리는 정도 | 낮을수록 좋음 |
| 활용도 | 실제 쿼리에서 인덱스 사용 빈도 | 높을수록 좋음 |
“느린 쿼리 하나가 서버 전체를 무너뜨릴 수 있다”
쿼리 튜닝은 성능 최적화의 첫걸음이자, 비용 절감의 핵심이다.
SQL 쿼리의 성능을 분석하고 개선하여 처리 속도를 높이는 작업
| 이유 | 설명 |
|---|---|
| 🐢 성능 저하 방지 | 느린 쿼리가 전체 API 응답 속도를 늦춤 |
| ⚡ 속도 향상 | 불필요한 연산 제거로 수백~수천 배 개선 가능 |
| 💸 비용 절감 | DB 서버 증설 없이도 성능 개선 |
| 👥 확장성 확보 | 더 많은 트래픽을 감당 가능 |
| 🧠 실력 차별화 | 고급 개발자는 튜닝 능력으로 차별화 |
| 항목 | 질문 |
|---|---|
| WHERE 조건에 인덱스가 걸려 있는가? | EXPLAIN으로 확인 |
| SELECT * 를 쓰고 있지는 않은가? | 필요한 컬럼만 조회 |
| 불필요한 JOIN이 있는가? | JOIN 조건 최적화 |
| ORDER BY, GROUP BY에서 Filesort가 발생하는가? | 인덱스로 해결 가능 여부 확인 |
| LIMIT 처리 방식이 효율적인가? | 페이징 최적화 (OFFSET 최소화) |
SELECT * FROM orders WHERE DATE(order_time) = '2025-08-07';
SELECT * FROM orders
WHERE order_time BETWEEN '2025-08-07 00:00:00' AND '2025-08-07 23:59:59';
| 전략 | 설명 |
|---|---|
| 📌 필요한 컬럼만 조회 | SELECT id, name 처럼 최소화 |
| 📌 조건 최적화 | 인덱스를 타도록 조건 작성 |
| 📌 조인 순서 조정 | 작은 테이블 먼저 접근 |
| 📌 통계 갱신 | ANALYZE TABLE로 옵티마이저 정보 최신화 |
| 📌 실행 계획 분석 | EXPLAIN, EXPLAIN ANALYZE 활용 |