느린 쿼리는 대부분 “데이터가 많아서”가 아니라 “원하는 순서로 찾지 못해서” 발생했다. 복합 인덱스 하나로 2.8초 검색을 300ms대로 줄였다.

explain 읽기
먼저 측정 가능한 기준을 정했습니다. 감으로 빠르다거나 편하다고 말하기보다, 응답 시간, 실패율, 유지보수 비용처럼 팀이 반복해서 볼 수 있는 지표를 앞에 뒀습니다.
CREATE INDEX CONCURRENTLY idx_posts_status_published
ON posts (status, published_at DESC);
복합 인덱스 순서
작게 도입한 뒤 한 주 동안 운영 데이터를 모았습니다. 예상보다 좋았던 부분은 개발 경험이었고, 예상보다 까다로웠던 부분은 예외 상황의 디버깅이었습니다.
삭제해야 할 인덱스
마지막 체크리스트는 단순합니다. 되돌릴 수 있는가, 실패를 관찰할 수 있는가, 팀원이 같은 결정을 다시 설명할 수 있는가. 이 세 가지가 통과되면 도입 리스크는 꽤 낮아집니다.
운영 메모
새 기술은 성능보다 운영 루틴을 먼저 흔듭니다. 알림, 로그, 롤백 경로를 같이 설계해야 오래 갑니다.
Comments
Google 계정으로 로그인 후 댓글 작성