분류
인덱스·쿼리 성능 · 2쪽
인덱스를 타지 않는 쿼리, 실행 계획 읽는 법, 페이지네이션과 COUNT 처럼 쿼리가 느려지는 이유와 고치는 법을 모았어요.
20편 · 마지막 글 2026.08.12
쿼리 글
20편 중 13–20
대량 적재 뒤 쿼리가 느려지면 — ANALYZE 와 낡은 통계
데이터를 대량으로 넣은 직후부터 쿼리가 느려졌다가 시간이 지나면 저절로 나아요. 그래서 원인을 못 찾고 다음 적재 때 또 반복되죠. 옵티마이저가 낡은 통계로 계획을 세우는 문제를 다뤄요.
인덱스가 있는데 안 타는 이유
인덱스를 만들었는데 쿼리는 그대로 느리고, 개발 DB 에선 잘 타던 인덱스를 운영에서만 안 타요. 옵티마이저가 인덱스를 못 쓰는 경우와 일부러 안 쓰는 경우를 가려내는 순서를 정리했어요.
소프트 삭제(deleted_at)가 느려지는 이유 — 부분 인덱스와 유니크 재설계
지운 데이터를 실제로 지우지 않고 표시만 해 뒀더니, 2년 뒤 테이블의 70%가 삭제된 행이 됐어요. 조회가 점점 느려지는 이유와 탈퇴한 이메일로 재가입이 막히는 문제를 함께 풀어요.
안 쓰는 인덱스 찾는 법 — pg_stat_user_indexes 로 지워도 되는지 판단하기
느릴 때마다 인덱스를 하나씩 더하다 보니 테이블 하나에 열두 개가 됐어요. 조회는 그대로인데 쓰기는 느려졌고요. 안 쓰는 인덱스를 찾는 법과 지워도 되는지 판단하는 기준을 정리했어요.
OFFSET 페이지네이션은 뒤로 갈수록 죽는다
목록 1페이지는 10ms 인데 100페이지쯤 가면 타임아웃이 나요. 사람보다 크롤러가 깊은 페이지를 훑을 때 터지는 이 문제를, 페이지 번호 대신 이어 읽기로 푸는 법을 보여 드려요.
ORM N+1 문제 — 쿼리가 101번 나가는 이유와 자동으로 잡는 법
목록 API 가 로컬에선 50ms 인데 운영에선 1.5초가 걸려요. 느린 쿼리는 하나도 없는데요. 코드 한 줄이 쿼리 101번이 되는 이유와 이걸 테스트로 미리 잡는 법을 알려 드려요.
LIKE '%검색어%' 는 인덱스를 못 쓴다
검색을 LIKE '%키워드%' 로 만들었더니 데이터가 늘면서 몇 초씩 걸려요. 인덱스를 걸어 뒀는데도요. 왜 인덱스가 소용없는지, 한국어 검색은 무엇으로 바꾸면 되는지 정리했어요.
복합 인덱스는 순서가 전부다
(status, created_at) 인덱스를 만들었는데 created_at 만으로 찾으면 인덱스를 안 타요. 그래서 인덱스를 자꾸 더 만들게 되죠. 컬럼 순서를 정하는 기준을 알면 오히려 개수가 줄어요.
조건에 맞는 글이 없어요. 브루니가 숨었나 봐요.