주먹구구식 쿼리 성능 분석은 그만...
언제까지 쿼리 하나하나 수정해가면서 '이건 빠른가? 느린가?' 하면서 튜닝하실 겁니까!
죄송합니다! 바로 제가 그랬습니다 ㅜㅠ
지금까지 얕은 전공 지식을 이용해서 데이터베이스 쿼리의 튜닝을 진행했었는데 너무 비효율적이었던 것 같습니다ㅋㅋㅋㅋ
당연하게도 쿼리가 데이터베이스에서 실제로 어떻게 실행될지 실행 계획을 보여주는 명령어가 있습니다.
바로 EXPLAIN 입니다.
PostgreSQL 공식 홈페이지의 USING EXPLAIN 페이지를 참고하여 EXPLAIN 사용법을 작성해봤습니다.
앞으로 쿼리의 성능을 튜닝해야 할 일이 있으면 무.작.정 쿼리를 작성하지 말고 최소한 EXPLAIN 명령을 사용합시다!
사용 방법
쿼리 앞에 EXPLAIN을 추가합니다. 너무 간단하죠? ㅋㅋㅋㅋ
- 예시) EXPLAIN SELECT * FROM test;
주어진 쿼리의 실행 계획을 예상하는 것이라서 정확하지 않을 수 있습니다.
그래서 EXPLAIN 명령어 뒤에 ANALYZE를 붙이면 쿼리를 직접 실행하면서 시간을 측정해줍니다.
※ 쿼리가 진짜 실행되니 주의해야 합니다! ※
- 예시) EXPLAIN ANALYZE SELECT * FROM test;
결과 해석
사용하기는 쉽지만 결과를 해석하기 어려운 경우도 많죠...
다행히도 EXPLAIN 명령어의 결과는 해석하기 그렇게 어려운 편은 아니더라구요!
예시)
EXPLAIN SELECT * FROM test;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on test (cost=0.00..458.00 rows=10000 width=244)
QUERY PLAN 밑에 쿼리 계획의 노드 별 결과가 트리 형태로 출력됩니다.
cost=0.00..458.00 이 보이시나요?
test 테이블의 10000개의 행을 스캔하는 것에 대해서 458.0 단위시간 만큼의 걸린다는 것을 뜻합니다.
그런데 한 줄 밖에 없는데 트리 형태가 무슨 뜻이냐구요?
EXPLAIN SELECT * FROM test WHERE unique1 < 100;
QUERY PLAN
------------------------------------------------------------------------------
Bitmap Heap Scan on test (cost=5.07..229.20 rows=101 width=244)
Recheck Cond: (unique1 < 100)
-> Bitmap Index Scan on test_unique1 (cost=0.00..5.04 rows=101 width=0)
Index Cond: (unique1 < 100)
INDEX, WHERE, ORDER BY 등이 추가될수록 결과가 늘어납니다!
상위 노드일수록 하위 노드의 결과를 합친 것인데 위의 결과를 해석하면
unique1의 index 스캔에(unique1이 100보다 작은 경우) 대해서 5.04 만큼의 단위 시간이 걸리고,
데이터들을 실제로 가져오는데 (229.0 - 5.07) 만큼의 시간이 걸린 것을 확인할 수 있습니다.
쿼리 실행 계획을 알려주는 EXPLAIN 명령어에 대해서 간단하게 알아봤습니다.
모두 효율적인 DB 쿼리 튜닝하세요!!!
'데이터베이스 > PostgresQL' 카테고리의 다른 글
PostgreSQL autoincrement - Oracle DB는 SERIAL이 없어요? (0) | 2022.10.15 |
---|---|
PostgreSQL 에러 "too many connections ~" 대응 방법 (0) | 2022.10.14 |
PostgreSQL 계정 비밀번호 바꾸기 (0) | 2022.10.09 |
PostgreSQL 기간 별 검색 최적화 (1) | 2022.10.02 |
PostgreSQL에서 DUAL 테이블 사용하기 (0) | 2022.09.22 |