분류
인덱스·쿼리 성능
인덱스를 타지 않는 쿼리, 실행 계획 읽는 법, 페이지네이션과 COUNT 처럼 쿼리가 느려지는 이유와 고치는 법을 모았어요.
20편 · 마지막 글 2026.08.12
쿼리 글
20편 중 1–12
느린 쿼리보다 총 시간 — pg_stat_statements 로 튜닝 순서 정하기
느린 쿼리 1등을 3초에서 0.5초로 줄였는데 서비스 체감은 그대로예요. 하루 500만 번 도는 50ms 쿼리가 더 큰 짐이었거든요. 튜닝할 쿼리를 고르는 기준을 바꾸는 법을 알 수 있어요.
조인 쿼리가 갑자기 느려졌을 때 — 추정이 어긋난 첫 노드 찾기
쿼리도 인덱스도 그대로인데 리포트 쿼리가 어느 날부터 100배 느려졌어요. 조인 순서가 뒤집힌 거예요. 옵티마이저가 순서를 잘못 고른 지점을 실행 계획에서 찾아 바로잡는 순서를 담았어요.
Index Scan 인데 느린 이유 — EXPLAIN BUFFERS 로 원인 가르기
EXPLAIN 에 인덱스 스캔이 찍혔는데도 쿼리가 3초씩 걸려요. 인덱스를 타는 건 시작일 뿐이거든요. 계획 아래 숫자 몇 개로 시간이 어디로 새는지 가려내는 법을 알 수 있어요.
인덱스 팽창(bloat) 확인하고 REINDEX CONCURRENTLY 로 줄이기
테이블은 그대로인데 인덱스만 몇 달에 걸쳐 조금씩 커져요. 다시 만들어 보면 크기가 절반으로 줄기도 하고요. 인덱스가 부푸는 패턴과, 서비스를 멈추지 않고 줄이는 법을 담았어요.
COUNT(*) 는 결국 다 세는 일이다
목록 스무 개는 10ms 에 나오는데 전체 개수를 세는 데는 3초가 걸려요. 인덱스를 더해도 크게 안 줄고요. 이 비용이 왜 구조적인지, 정확한 숫자 대신 무엇을 보여 줄 수 있는지 알 수 있어요.
NOT IN 에 NULL 이 섞이면 결과가 0건 — NULL 과 인덱스
NOT IN 으로 걸렀는데 에러도 없이 결과가 0건이에요. 데이터는 분명히 있는데요. NULL 하나가 결과를 통째로 비우는 이유와, DB 마다 NULL 을 다르게 다루는 지점을 짚었어요.
OR 조건이 인덱스를 못 타는 이유 — UNION·IN 으로 나누기
검색 조건에 OR 하나를 더했을 뿐인데 쿼리가 갑자기 느려져요. AND 로 바꾸면 멀쩡하고요. 어떤 OR 은 괜찮고 어떤 OR 만 인덱스를 놓치는지, 그 기준과 고쳐 쓰는 법을 알 수 있어요.
여섯 번째 실행부터 느려지는 쿼리 — PostgreSQL generic plan 문제
같은 쿼리가 다섯 번까지는 빠르다가 여섯 번째부터 느려지고, 서버를 재시작하면 다시 빨라져요. 우연 같은 이 숫자 뒤에 있는 PostgreSQL 의 규칙과 피하는 법을 정리했어요.
정렬이 디스크로 넘어갈 때 — work_mem 과 external merge
정렬이 들어간 쿼리가 평소엔 빠른데 트래픽이 몰리는 시간에만 수십 배 느려져요. 혼자 재현하면 멀쩡한 이 현상이 왜 생기는지, 서버를 위험하게 하지 않고 고치는 법을 담았어요.
인덱스 온리 스캔이 안 되는 이유
필요한 컬럼을 전부 인덱스에 넣었는데 PostgreSQL 이 여전히 테이블을 읽어요. 대량 갱신 직후엔 느리다가 한참 지나면 저절로 빨라지고요. 그 「한참」 동안 무슨 일이 일어나는지 풀어 드려요.
LIMIT 이 붙으면 계획이 통째로 바뀐다
LIMIT 10 을 붙였더니 오히려 느려졌어요. LIMIT 10 은 0.1초인데 LIMIT 100 은 12초가 걸리기도 하고요. LIMIT 값 하나에 옵티마이저가 계획을 통째로 바꾸는 이유와 대처법을 정리했어요.
EXPLAIN ANALYZE 읽는 법 — 추정 행 수와 실제 행 수 비교하기
느린 쿼리를 잡으려고 EXPLAIN 을 열어도 숫자가 무슨 뜻인지 모르겠어요. 인덱스 스캔인데도 느리면 더 막막하고요. 실행 계획에서 먼저 봐야 할 두 숫자와 읽는 순서를 정리했어요.
조건에 맞는 글이 없어요. 브루니가 숨었나 봐요.