어제 내가 만든 부분을 실서버에서 테스트해봤는데 속도가 좀 느린 것 같았다.
해당 서버가 원래 대량 데이터 처리속도가 느리고 데이터가 많아서 그런 거일 수도 있었지만 그래도 쿼리 튜닝을 해봐야겠다고 생각해서 다른 개발자분께 여쭤도 보고 혼자 공부했다.
기존 쿼리도 괜찮긴 하지만 몇 가지 수정이 필요하다고 하시면서 "계획 설명"에 대해서도 알려주시고, 쿼리도 짜주셨다ㅠㅠ 기존과 수정된 쿼리를 혼자 비교하면서 계획 설명도 보면서 공부했다.
계획 설명(단축키 : F10)에서는 옵티마이저가 어떤 방식으로 쿼리를 실행시키는지를 알 수 있다.
테이블명도 나오기 때문에 어느 위치에서 어떻게 실행되는지 한 눈에 보기 편하다.
나는 속도를 위해 쿼리튜닝을 하는 중이었으므로 스캔방식, cardinality에 중점을 두고 살펴봤다.
쿼리가 어떤 방식으로 실행되는지 (join방식, scan방식 등) 살펴볼 수 있는데 처음 보다보니 용어가 낯설어서 정리해봤다.
1. Execuation Plan
- SQL 실행 시 최적화 단계에서 옵티마이저가 만들어 내는 SQL 실행을 위한 방법, 단계, 순서를 기술한 것
- table 및 index는 어떤 식으로 접근하는지, 조인은 hash, merge, nested loop 중 어떤 조인을 사용하는지
table 조인 순서는 어떤 table을 먼저 할 것인지,어떤 sql 연산을 이용하는지 (필터, 정렬, 집계 등)에 관해
옵티마이저가 실행계획의 각 단계마다 예상되는 비용 사항을 표시하는 최적화 정보이다.
2. predicate
- condition of record
- where 조건
- 인덱스 접근시의 컬럼 액세스 정보, 조인 정보, filter 정보를 각 Opreation 단위로 나 타낸 것이다.
3. filter predicates
- 데이터 블록을 읽고 나서 데이터를 어떻게 필터링 했는지를 나타낸다.
- INDEX 컬럼 아닌 경우
- discard non-matching rows
4. access predicates
- 데이터 블록을 어떤 방식으로 Access해서 읽었는지를 나타내는 것이다.
- INDEX 에 컬럼이 있는 경우
- only fetch matching rows
5. 카디널리티
- 행 집합에서 행의 수를 나타낸다. 여기서 행 집합은 기본 테이블, 뷰, 조인이나 group by의 결과일 수 있다.
- base cardinality, distinct cardinality, join cardinality 등 여러 종류가 있다.
- join cardinality : 두 행 집합이 함께 조인되었을 때 생산된 행의 수이다.
두 행 집합들의 카티션 곱이라고 한다.
아래는 수정 전 쿼리의 실행 계획이다. 132는 cardinality인데, 로컬이라서 로우 수가 별로 없는데도 꽤 높게 나왔다.
행이 많지도 않은데 full scan을 돌아서 cardinality가 높게 나온거 같아서 이런 부분을 보고 수정이 필요하구나를 알게 되었다.
6. cost
- 옵티마이저가 측정한 오퍼레이션 수행에 필요한 예측비용
- cost 수치가 낮을 수록 좋은 성능을 예상할 수 있다. 하지만 말 그대로 예측 비용이므로 수치가 낮다고 반드시 빠른 것은 아니다.
쿼리 튜닝을 위해서 join 방식도 공부하고 여러 튜닝 관련 정보들도 공부했는데
이는 더 공부할 것이다.
*참고자료
1. 오라클 Execuation plan이란 : https://www.youtube.com/watch?v=SYUxsqhzNRQ
2. Execuation plan 용어 설명 : https://shj7242.github.io/2019/02/15/CLASS5/
3. Execuation plan 용어 설명(영어) : https://www.youtube.com/watch?v=K0f2Yzue7yw
4. 카디널리티 : https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=m30winjv&logNo=90027984599
5. 오라클 Execuation plan이란 : https://www.nextree.co.kr/oracle-explain-plan-sayong/