PostgreSQL에서 실행 계획을 조회하고 성능 최적화 시도하기 - dnwls16071/Backend_Summary GitHub Wiki
❓왜 성능 최적화를 시도하는지?
회사에서 백오피스 서비스 개발을 담당하고 있다. 백오피스 서비스의 경우는 클라이언트 측과 달리 제한된 사용자에게만 인가 권한이 부여되기 때문에 트래픽은 적을 수 있다. 백오피스 특성상 서비스 관리에 초점이 맞춰지기 때문에 INSERT, UPDATE, DELETE보다 SELECT를 더 많이 사용하기 때문에 데이터가 많아질 시를 대비해서 조회 성능 최적화를 해두는 것이 좋을 것 같다고 생각했다.
이 과정에서 인덱스를 사용하기로 했다. 인덱스가 "조회 성능 최적화"라는 장점만 있는 것은 아니다. 인덱스도 엄연히 테이블이기 때문에 그만큼의 저장 용량을 차지한다. 그렇기 때문에 조회가 빈번히 발생하는 부분과 데이터가 많아질 경우 조회 성능을 극한으로 끌어올리기 위해 인덱스 도입을 기획하게 되었다.
회사에서 MySQL과 PostgreSQL를 사용하고 있으나 내가 맡은 서버의 데이터베이스는 PostgreSQL이라 이번 기회에 경험해보고자 한다.
📚 PostgreSQL에서 실행 계획 읽는 방법
Seq Scan on enterprise_user (cost=0.00..1.29 rows=23 width=37) (actual time=0.011..0.017 rows=18 loops=1)
Filter: ((enterprise_id)::text = '55339e98-6ec0-4022-aeef-f0820b26c855'::text)
Rows Removed by Filter: 5
Planning Time: 0.120 ms
Execution Time: 0.033 ms
1. Seq Scan on enterprise_user⭐⭐
- enterprise_user 테이블을 처음부터 끝까지 순차적으로 읽는다.(인덱스를 사용하지 않음)
2. cost=0.00..1.29
- 0.00 : 첫 번째 행을 가져오는 비용
- 1.29 : 모든 행을 가져오는 총 비용
3. rows=23 width=37
- rows=23 : 예상 결과 행 수
- width=37 : 각 행의 평균 바이트 크기
4. actual time=0.011..0.017 rows=18 loops=1⭐⭐
- 0.011ms: 첫 번째 행 반환 시간
- 0.017ms: 전체 실행 완료 시간
- rows=18: 실제 반환된 행 수
- loops=1: 이 작업을 1번 실행
5. Filter: ((enterprise_id)::text = '55339e98-6ec0-4022-aeef-f0820b26c855'::text)
Rows Removed by Filter: 5
- 총 23행을 읽어서 조건에 맞지 않는 5행을 제거
6. Planning Time: 0.120 ms (쿼리 계획 수립 시간)
7. Execution Time: 0.033 ms (실제 실행 시간)⭐⭐
Execution Time이 100ms 이상이면 → 개선 필요
Seq Scan이면서 데이터가 많으면 → 인덱스 고려