2021 02 08

*DBMS의 쿼리 처리 흐름

1) 쿼리를 파싱한다

/* 옵티마이저 (최적화의 영역이다)*/

2) 파싱된 쿼리를 가지고 실행계획을 작성한다.

3) 비용을 연산하고 가장 낮은 비용의 계획을 선택한다.

/* 옵티마이저 (최적화의 영역이다)*/

4) 카탈로그 매니저(통계정보) - 옵티마이저가 실행계획을 세울때 중요한 정보를 제공하는것.

DBMS의 내부정보를 모아놓은 테이블들. 

5) 플랜 평가 - 옵티마이저로부터 실행계획을 받아서 최적의 실행 결과를 선택하는것. 곧바로 DBMS가 실행할 수 있는 형태의 코드가 아니기 때문에 수정방안 등을 고려할 수 있다.

 

*옵티마이저와 통계정보

하지만 옵티마이저도 만능은 아니다. 통계정보는 데이터베이스 엔지니어가 관리해줘야 한다.

통계정보가 부족한 경우 옵티마이저가 실패하는 경우도 있다. 테이블 또는 인덱스의 실제와 일치하지 않을때 발생한다.

통계정보를 예를들자면 다음과 같은 예시가 있다.

- 각 테이블의 레코드 수 및 필드 수와 필드의 크기...

- 인덱스 정보

 

* 조건분기

1) WHERE절만 다르게한 SELECT 구문을 합쳐서, 복수의 조건에 일치하는 하나의 결과집합을 얻는데 사용한다.

-> 내부적으로 여러개의 SELECT구문을 사용하기 때문에 I/O비용이 늘어난다.

 

SELECT item_name, year, price_tax_ex AS price
	FROM items
WHERE year <= 2001
UNION ALL
SELECT item_name, year, price_tax_ex AS price
	FROM items
WHERE year >= 2002

UNION을 사용했을때 안고있는 문제점

- 똑같은 쿼리가 반복된다.

- 테이블을 두번 스캔한다.

 

2) WHERE 구에서 조건분기를 하는 사람은 초보자. 잘하는 사람은 SELECT 구만으로도 조건 분기를 한다.

SELECT item_name, year,
	CASE WHEN year <= 2001 THEN price_tax_ex
    CASE WHEN year >= 2002 THEN price_tax_in 
    END AS price
FROM items;

위와 아래는 같은 결과를 출력하지만 CASE를 사용한 쿼리가 훨씬 성능적으로 좋다.

 

UNION 쿼리는 Items테이블에 TABLE ACCESS FULL접근이 2회 발생한다. 

반면 CASE식을 사용한 실행계획은 TABLE ACCESS FULL 접근이 1회로 줄어든다.

 

* SQL 구문의 성능이 좋은지 나쁜지는 반드시 실행 계획 레벨에서 판단해야 한다. SQL구문에는 데이터를 검색할지를 나타내는 접근 경로가 쓰여있지 않기 때문.

 

*IF 조건문을 사용할 때마다 이것을 SQL의 CASE로는 어떻게 해결할 수 있을까? 라는것을 꾸준히 생각하도록 하자.