[데이터베이스] SQL 튜닝 - 드라이빙 테이블

 

데이터베이스를 통해 데이터를 가져올 때 테이블의 엑세스 순서에 따라서 성능이 좌지우지 되는 경우가 있습니다.

특히 데이터가 많은 경우에는 이러한 성능을 개선해주는 튜닝이 중요해지게 됩니다.

이번 글에서는 이 DB튜닝에서 사용되는 드라이빙 테이블에 대해서 알아보겠습니다.

 

 

 

드라이빙 테이블이란

 

드라이빙 테이블은 join시에 먼저 엑세스 되는 테이블을 의미합니다.

반대로 나중에 엑세스되는 테이블은 드리븐 테이블, 혹은 이너 테이블이라고 합니다.

이 때 드라이빙 테이블이 될 것인지, 즉 어떤 테이블을 먼저 엑세스 할 것인지가 중요합니다.

예시로 아래의 상황을 들 수 있습니다.

 

만약 찾고자 하는 조건에 맞는 행이 A테이블에 5000만건, B테이블에 1000만건이 있을 때

where A.no = B.no 를 수행한다고 하면

 

1. A테이블이 드라이빙이면

A테이블의 1번째 행의 no를 B테이블에서 찾아 매칭되는지 확인

A테이블의 2번째 행의 no를 B테이블에서 찾아 매칭되는지 확인

A테이블의 3번째 행의 no를 B테이블에서 찾아 매칭되는지 확인

...

이렇게 A테이블이 B테이블을 5000만번 조회해야 합니다.

 

2. B테이블이 드라이빙이면

1번과 동일한 방식으로 B테이블이 1000만번 A테이블을 조회해야 합니다.

 

위의 경우를 보았을 때 한 테이블을 5000만번 조회하는 것과 1000만번 조회하는 것은 속도면에서 큰 차이가 있게 됩니다.

결국에는 만족하는 데이터 수가 작은 A테이블이 드라이빙 테이블이 되어 먼저 엑세스되고, 후에 데이터 수가 큰 B테이블을 엑세스해야 성능면에서 더 유리합니다.

이렇듯 누가 드라이빙 테이블이 될 것인지는 성능에 영향을 미치는 중요한 요소가 됩니다.

 

그러면 데이터베이스는 어떤 테이블을 드라이빙 테이블로 결정할까요?

 

 

 

비용기반 옵티마이저에서의 결정규칙

 

누가 드라이빙 테이블이 될지는 데이터베이스의 핵심 엔진인 옵타마이저가 결정합니다.

옵티마이저는 SQL을 가장 효율적으로 처리할 수 있도록 처리 경로를 결정해주는 데이터베이스의 관리 시스템이죠.

옵티마이저는 규칙기반 옵티마이저(Rule-Based Optimizer)와 비용기반 옵티마이저(Cost-Based Optimizer)가 있습니다.

이번 글에서는 흔하게 사용되는 비용기반 옵티마이저의 결정 방식을 다루겠습니다.

 

where A.no = B.no

위의 join이 일어나면 우선 테이블의 인덱스 유무를 살피게 됩니다.

 

그 이유는 인덱스가 있다면 데이터 조회 시에 Full Scan이 일어나지 않기 때문에 인덱스가 있는 테이블을 드리븐 테이블로 두면 드라이빙 테이블이 드리븐 테이블에 대해서 반복적으로 Full Scan을 하지 않아 더 빠르기 때문입니다.

따라서 인덱스가 한쪽 테이블에만 있으면, 인덱스가 없는 테이블을 드라이빙 테이블로 하게 됩니다.

하지만 양쪽 모두 인덱스가 있거나, 양쪽 모두 없다면 각 테이블의 레코드 건수나 이외 통계 정보 등에 따라 옵티마이저가 드라이빙 테이블을 판단하게 됩니다.