DailyLog DB Index 1차 최적화 기록

DailyLog 프로젝트에서 캘린더 기반 조회, 최근 기록 조회 기능을 구현하면서
데이터가 늘어날 경우를 대비해 MySQL 인덱스 최적화 작업을 진행했다.

이번 글에서는

왜 인덱스가 필요한지 → 어떤 인덱스를 추가했는지 → 실제로 인덱스를 타는지
를 EXPLAIN 기준으로 정리한다.

---

1️⃣ 현재 문제 인식

초기 상태의 daily_log 테이블은 다음과 같았다.

SHOW INDEX FROM daily_log;

결과

• PRIMARY KEY (id)만 존재
• log_date, category 관련 인덱스 없음

즉,

• 날짜 기반 조회
• 최근 7일 조회
• 월 단위 캘린더 조회
• 카테고리 필터

모두 풀 테이블 스캔(Full Scan) 상태였다.

데이터가 적을 때는 문제가 없어 보이지만,
데이터가 쌓이면 성능 저하가 바로 발생할 수 있는 구조였다.

---

2️⃣ 사용 패턴 분석

DailyLog에서 실제로 발생하는 조회 패턴은 다음과 같다.

• 📅 월 단위 캘린더 조회 (log_date BETWEEN)
• 🕒 최근 7일 기록 조회
• 🏋️ 최근 7일 중 EXERCISE 우선 노출
• 📌 특정 날짜 클릭 조회

→ 모든 쿼리의 중심은 log_date

---

3️⃣ 인덱스 설계 전략

✅ 필수 인덱스: log_date

ALTER TABLE daily_log
ADD INDEX idx_daily_log_log_date (log_date);

• 날짜 범위 조회 최적화
• 캘린더/최근 기록/날짜 클릭 전부 커버

---

✅ 복합 인덱스: (log_date, category)

ALTER TABLE daily_log
ADD INDEX idx_daily_log_log_date_category (log_date, category);

• 최근 7일 + 카테고리 필터
• 향후 통계/집계 대비

복합 인덱스는 왼쪽 컬럼부터 사용되므로
log_date → category 순서가 중요하다.

---

4️⃣ 인덱스 적용 결과

SHOW INDEX FROM daily_log;

결과 요약

Index Name	Columns
PRIMARY	id
idx_daily_log_log_date	log_date
idx_daily_log_log_date_category	log_date, category

👉 의도한 인덱스가 정확히 적용됨.

---

5️⃣ 인덱스가 실제로 사용되는지 확인 (EXPLAIN)

① 월 단위 조회 (캘린더)

EXPLAIN
SELECT *
FROM daily_log
WHERE log_date >= '2025-12-01'
  AND log_date <  '2026-01-01'
ORDER BY log_date DESC, created_at DESC;

기대 결과

• type = range
• key = idx_daily_log_log_date 또는 복합 인덱스

결과값

---

② 최근 7일 조회

EXPLAIN
SELECT id, title, category, log_date
FROM daily_log
WHERE log_date >= CURDATE() - INTERVAL 6 DAY
  AND log_date <= CURDATE()
ORDER BY log_date DESC;

결과값

---

③ 최근 7일 + 카테고리 필터

EXPLAIN
SELECT id, title, category, log_date
FROM daily_log
WHERE log_date >= CURDATE() - INTERVAL 6 DAY
  AND log_date <= CURDATE()
  AND category = 'EXERCISE'
ORDER BY log_date DESC;

기대 결과

• key = idx_daily_log_log_date_category
• type = range 또는 ref

결과값

---

④ 특정 날짜 클릭 조회

EXPLAIN
SELECT id, title, category, log_date
FROM daily_log
WHERE log_date = '2025-12-12'
ORDER BY created_at DESC;

결과값

---

6️⃣ 인덱스 사용 여부 체크 포인트

EXPLAIN 결과에서 아래만 보면 된다.

컬럼	의미
type	ALL이면 풀스캔, range/ref면 정상
key	실제 사용된 인덱스
rows	예상 스캔 row 수
Extra	Using where, Using filesort 여부

⚠️ 특히 아래 형태는 인덱스를 못 탄다:

WHERE DATE(log_date) = '2025-12-12'

반드시 이렇게 써야 한다:

WHERE log_date = '2025-12-12'

---

7️⃣ 결론

• 테이블 구조 변경 ❌
• 데이터 삭제 ❌
• 인덱스 추가만으로 구조 안정화 완료 ✅

“구조는 이미 맞았고, DB가 그 구조를 제대로 받쳐줄 차례였다.”

이번 작업으로 DailyLog는
데이터가 늘어나도 프론트 구조를 바꾸지 않아도 되는 상태가 되었다.