Driving 테이블
조인시 먼저 액세스되는 쪽을 드라이빙 테이블(DRIVING TABLE, OUTER TABLE)이라고 하며 나중에 액세스 되는 테이블을 드리븐 테이블(DRIVEN TABLE, INNER TABLE)이라고 합니다.
인덱스(INDEX)의 존재 및 우선순위 혹은 FROM 절에서의 TABLE 지정 순서에 영향을 받으며 어느 테이블이 먼저 액세스되느냐에 따라 속도의 차이가 크게 날 수 있으므로 대량의 데이터를 다룰 때 정말 중요합니다.
조건을 만족하는 테이블과 해당하는 로우 데이터 수가 다음과 같다고 가정합니다.
A 테이블: 1억건
B 테이블: 100건
이 때, 조인시 드라이빙 순서에 따라 속도의 확연한 차이가 발생할 수 있습니다.
A 테이블을 드라이빙하게 되면 최대 1억 번을 반복하며 B 테이블을 탐색하고,
B 테이블을 드라이빙하게 되면 최대 100 번을 반복하여 A 테이블을 탐색합니다.
즉, 작업 대상이 되는 행(rows)의 수가 적은 테이블부터 액세스 되어야 전체 탐색이 줄어듭니다. 드리븐 테이블의 인덱스 유무에 따라 풀 스캔이 수행될 수 있습니다. 인덱스가 있다면 풀 테이블 스캔이 아닌 인덱스를 통해서 효율적으로 레코드를 찾습니다.
드라이빙 테이블 결정 규칙
규칙기반 옵티마이저(Rule-Based Optimizer, RBO)
- 인덱스를 이용한 액세스 방식이 전체 테이블 액세스 방식보다 우선순위가 높음
- 조인 컬럼에 대한 인덱스가 양쪽 테이블에 모두 존재할 때, 우선순위가 높은 테이블을 선택
- 조인 컬럼에만 인덱스가 존재하는 경우에는 인덱스가 없는 테이블을 먼저 선택하여 조인 실행
- 만약 조인 테이블의 우선순위가 동일하지 않다면, FROM 절에 나열된 테이블의 역순으로 수행
우선순위가 높은 테이블이란 무엇일까?
규칙기반 옵티마이저의 경우 일반적으로 다음과 같은 요소를 확인하여 드라이빙 테이블을 선정합니다.
판단 요소 | 내용 |
테이블 크기 | 일반적으로 작은 테이블이 우선순위가 높은 테이블로 간주 |
필터링 조건 | WHERE 또는 ON 조건으로 필터링될 가능성이 높은 테이블이 우선 선택합니다. 데이터 양을 줄여 드라이빙 테이블로써 성능을 높이기 위함입니다. |
인덱스 유무 | 조인 컬럼에 인덱스가 양쪽 테이블에 모두 존재하는 경우라도, 더 효율적으로 활용될 인덱스를 가진 테이블이 우선 선택됩니다. 예시, B-tree 인덱스가 해시 인덱스보다 우선순위가 높습니다. |
드라이빙 테이블을 읽는 비용 (Access Cost) | 테이블 스캔 비용이 더 낮은 테이블이 우선순위가 높습니다. 예시, In-memory table이 디스크 기반 테이블보다 우선 선택됩니다. |
조인의 형태 | 특정 조인 유형에 따라 우선순위가 달라질 수 있습니다. 예시, STRAIGHT_JOIN를 사용할 경우 명시된 테이블 순서로 정해짐 |
메모리 내 테이블 (In-memory table)
메모리에 데이터를 저장하고 관리하는 테이블이며 주로 속도가 중요한 작업에 사용됩니다.
MySQL는 MEMORY 엔진이 메모리 내 테이블을 제공합니다.
예) ENGINE = MEMORY
https://dev.mysql.com/doc/refman/8.4/en/memory-storage-engine.html
디스크 기반 테이블 (Disk-Based Table)
디스크에 데이터를 저장하는 방식으로 작동하는 테이블입니다.
MySQL의 기본 스토리지 엔진인 InnoDB와 같은 엔진이 디스크 기반 테이블을 제공합니다.
만약 조인 테이블의 우선순위가 동일하지 않다면, FROM 절에 나열된 테이블의 역순으로 수행하는 이유는 무엇일까?
조인 전략의 일관성 유지
- RBO는 복잡한 최적화 작업을 수행하지 않으므로, 일관된 순서를 유지해야 합니다. 역순으로 처리하는 것은 하나의 규칙으로, 모든 쿼리에 동일한 방식으로 적용됩니다.
구현의 단순성
- 역순 처리 규칙은 옵티마이저의 복잡성을 낮춥니다. 테이블을 역순으로 처리하면 스택 구조를 이용한 간단한 알고리즘으로 구현할 수 있습니다.
조인 조건의 처리 방식
- RBO는 조인 조건을 테이블 간의 연결 순서에 따라 처리합니다. 역순으로 처리하면 최종 결과를 역으로 따라 올라가며 필요한 조건을 적용하는 방식으로 구현이 용이합니다.
비용기반 옵티마이저(Cost-Based Optimizer, CBO)
- 규칙의 우선순위가 아닌 쿼리를 수행하는데 소요되는 예상 비용을 바탕으로 실행계획을 생성
- 통계정보, DBMS 설정 정보, DBMS 버전 등의 차이로 인해 똑같은 SQL문이라도 서로 다른 실행계획이 생성될 수 있음
아래는 예시를 들어 설명을 하겠습니다.
SELECT *
FROM employees e, dept_emp de
WHERE e.emp_no = de.emp_no;
케이스 | 내용 |
모두 인덱스가 있는 경우 | 옵티마이저의 판단으로 각 테이블의 통계 정보에 있는 레코드 건수에 따라 드라이빙 테이블을 결정 |
dept_emp.emp_no 인덱스 | employess 테이블의 풀 스캔을 막기 위해 인덱스가 있는 dept_emp 테이블을 드리븐 테이블로 결정 |
employees.emp_no 인덱스 | dept_emp 테이블의 풀 스캔을 막기 위해 인덱스가 있는 employees 테이블을 드리븐 테이블로 결정 |
모두 인덱스가 없는 경우 | 레코드 수에 따라 옵티마이저가 드라이빙 테이블을 결정합니다. 모두 인덱스가 없을 경우 드리븐 테이블을 풀 스캔합니다. |
현재는 비용 기반 옵티마이저를 더 많이 사용합니다.
비용 기반 옵티마이저(CBO)의 장점은 실제 실행 비용 기반의 최적화가 이뤄지고 동적이며 지능적이라는 점입니다. 또한 대규모 데이터 처리에 적합합니다. 반면에 규칙 기반 옵티마이저인 (RBO)는 정적인 규칙만 사용하고, 최적화 능력이 부족하며, 병렬 처리와 클러스터링, 분산 데이터베이스 같은 현대적인 기능과의 부조화가 있습니다. 따라서 비용 기반 옵타마이저가 현대 DBMS의 표준이며 RBO는 대부분의 상황에서 더 이상 사용되지 않습니다.
하지만 비용 기반 옵티마이저를 깊게 알기 위해서는 규칙 기반 옵티마이저의 동작에 대해서 아는 것이 중요합니다.
Reference
GPT
'[개발] 데이터베이스 > MySQL' 카테고리의 다른 글
트랜잭션 격리 수준 (0) | 2024.10.26 |
---|---|
에러) Column in field list is ambiguous (0) | 2024.10.23 |
MySQL 프로시저를 자바 코드로 이관 (0) | 2023.11.13 |
MySQL) DATABASE 에서 가장 큰 용량을 지닌 테이블 조회하기 (0) | 2021.09.09 |
MySQL Server 설치 오류시 해결방법 (0) | 2017.12.02 |