SQL 튜닝과 Table Access

SQL 튜닝을 왜 해야 할까요 그러면?

사실 그렇잖아요, 뼈빠지게 쿼리를 열심히 짰는데.. 튜닝까지 해야 한다고?

랜덤I/O로 인한 비효율을 최소화하기 위해 필요합니다.

그러려면 어제 길게길게 설명한 인덱스 스캔 방식도 중요하지만, 이게 만능은 또 아니란 말이지요.

알면 알 수록 알아야할 게 많아지는 건 어디나 마찬가지고 여기도 예외가 없다 이겁니다..

 

그래서 테이블을 어떻게 액세스해서 찾아들어가는지에 대해서도 알아야 합니다.

 

SQL 조건에서 참조하는 칼럼을 인덱스가 모두 포함하지 않는다면, 인덱스 스캔 후에 테이블을 반드시 한번 더 읽어야 합니다.

table access by local index rowid - 테이블을 한번더 액세스를 해야합니다.ㅠㅠ

스캔을 통해 조건에 맞는 소량의 데이터를 빨리 찾아내요.

근데 그 데이터를 ROWID로 찾는다 말이죠?

ROWID는 테이블 레코드를 찾기 위한 주소값이에요.

그 ROWID를 이용해서 테이블 레코드를 찾아가기 위해서 인덱스가 필요해요.

 

2020년 11월 KITRI에서 튜닝 외부교육 들을 때 강사님이 사용하셨던 자료인데 솔직히 이렇게 간만에 보니까 가물가물 함..

구조적인 이야기가 솔직히 전 그렇게 재밌진 않아요.

사실 정파 컴퓨터공학을 전공하지 않은 사파 개발자라서 제대로 배운 적도 거의 없어요. 네 맞아요 근본이 없음ㅋㅋ..

근데 이해를 돕기 위해 2020년 11월에 KITRI 튜닝교육 들었을때 주워들은 얘기를 좀 더 해보자면..

 

오라클 같은 디스크 DB는 데이터를 가져오기 위해 버퍼캐시 메모리에 테이블 블록을 올려요.

그런데 버퍼캐시에 올라가는 테이블 블록은 수시로 변경되고, 다른 공간에 캐싱되고 하겠죠.

그래서 인덱스에서는 메모리 주소의 정보가 아닌 테이블, 데이터가 저장된 디스크 주소의 정보를 이용하여, 해시 알고리즘을 통해 버퍼 블록을 찾아야해요.

I/O 작업 속도도 느리고 비용도 많이 들고 불편하죠.

 

그래서 읽어야 할 데이터가 일정량을 넘어가면 테이블 전체 스캔보다 인덱스 스캔이 오히려 더 느려지게 돼요.

사실 위에 구조 설명 이해 못해도 괜찮으니 이거 한 줄만 건지면 돼요.ㅋㅋㅋ

 

INDEX RANGE SCAN에 의한 테이블 액세스가 TABLE FULL SCAN보다 느려지는 지점을 인덱스 손익분기점이라고 부릅니다.

INDEX RANGE SCAN VS TABLE FULL SCAN

그리고 스캔만 영향을 미치는 게 또 아니에요.

클러스터링 팩터(Clustering factor, 군집성 계수)도 영향을 미칩니다.

클러스터링 팩터는 특정 컬럼을 기준으로, 같은 값을 갖는 데이터가 서로 모여있는 정도를 의미합니다.

값의 가짓수가 적으면 군집도가 높고, 클러스터링 팩터도 좋습니다. ex) 성별: 일반적으로 남성/여성 2가지로 나누어짐

하지만 가짓수가 너무 많은 지표라면, 예를 들면 연봉이 있을 텐데요. 이런 건 클러스터링 팩터가 좋다고 보기 힘들겠죠. 사람마다 얼마를 버는지는 천차만별일 테니까요.

 

같은 테이블을 반복적으로 액세스하면서 I/O가 늘어난다면 손익분기점이 전체 테이블의 1~5% 미만의 적은 값으로 설정될 수 있어요.

무조건 인덱스 스캔방식으로 스캔을 하는게 유리하지 않습니다.

테이블을 액세스하는 근본적인 방식부터 고찰해볼 필요가 있을 수도 있어요.

비효율적으로 접근하는 엑세스는 없는지 같은 부분에서 줄일 곳이 나올 수 있다는 얘깁니다.

 

여담.

글쓰다보니 2020년에 취득한 SQLD 책에 튜닝이 있어서 이게 뭐지 봤더니 SQLP범위 문제라고 봤던 것 같은데..

저는 멍청하지만 나중에 기회되면 한번 따보고 싶긴 해요.

ADP SQLP 극악의 난이도를 자랑한다 듣긴했습니다만...