EXPLAIN ANALYZE 출력은 실제로 중요한 세 숫자를 알기 전까지는 위협적으로 보입니다. 여기 내가 그것들을 읽는 순서와 특정 버그를 가리키는 패턴이 있습니다.
실제로 중요한 세 숫자
1. 총 실행 시간 (Total Execution Time)
Total runtime: 1234.567 ms
가장 중요한 지표입니다. 쿼리가 느리면 여기에서 알려줍니다.
2. 실제 행 수 vs 예상 행 수 (Actual vs Estimated Rows)
Seq Scan on users (cost=0.00..123.45 rows=1000 width=32) (actual time=1.234..567.890 rows=50000 loops=1)
거대한 차이는 플래너가 잘못된 가정을 했다는 것을 나타냅니다.
3. 버퍼 히트 비율 (Buffer Hit Ratio)
Buffers: shared hit=1000 read=50
높은 히트율 = 좋은 캐시 사용, 낮은 히트율 = 디스크 I/O 문제.
읽는 순서
- 아래에서 시작 - 총 실행 시간
- 위쪽으로 작업 - 가장 비용이 많이 드는 노드 찾기
- 행 수 추정 확인 - 실제 vs 추정
- 버퍼 통계 보기 - I/O 패턴
일반적인 문제 패턴
인덱스 스캔이어야 할 때 순차 스캔
Seq Scan on large_table (cost=1000.00..2000.00 rows=100000 width=32)
해결책: 적절한 인덱스 추가
해시 조인이어야 할 때 중첩 루프
Nested Loop (cost=1000.00..100000.00 rows=1000 width=64)
-> Seq Scan on users
-> Index Scan on orders
해결책: work_mem 증가 또는 쿼리 재작성
너무 많은 버퍼 미스
Buffers: shared hit=10 read=1000
해결책: shared_buffers 증가 또는 쿼리 개선
디스크로 정렬 오버플로
Sort Method: external merge Disk: 16384kB
해결책: work_mem 증가
실제 적용
이러한 통찰은 내가 식별하고 수정하는 데 도움이 되었습니다:
- 누락된 인덱스
- 비효율적인 조인 순서
- 메모리 부족 문제
- 캐시 미스
기억하세요: EXPLAIN ANALYZE는 쿼리 성능 디버거입니다. 그것을 읽는 법을 배우면 추측에 수많은 시간을 절약할 수 있습니다.