SQL BOOSTER - SQL 작성 가이드(3)

 

1. 작업량을 줄이자

 

SQL 성능을 높이려면 IO를 개선하는 것이 기본 원칙이다. IO를 더 줄일 수 없다면 작업량을 줄이는 아이디어가 필요하다. 

 

SELECT T1.CUS_ID,
       SUM(T1.UNT_PRC * T1.ORD_QTY)ORD_AMT
       , SUM(CASE WHEN T1.ORD_YMD LIKE '201701%' THEN T1.UNT_PRC * T1.ORD_QTY END) AMT_01
       --12월까지 반복 
       
FROM T_ORD_JOIN T1
GROUP BY T1.CUS_ID
ORDER BY SUM(T1.UNT_PRC * T1.ORD_QTY) DESC;

 

위 SQL은 WHERE 조건절이 없다. 따라서 T_ORD_JOIN 모두를 읽어야 한다. 위 SQL의 실행계획은 아래와 같다.

SQL BOOSTER

 

위 SQL의 성능을 개선해보자 CASE가 12번 사용되고, T_ORD_BIG에는 3백만 건 정도의 데이터가 있다.

그러므로 3백만 * 12번 처리된다고 추론할 수 있다. CASE문의 횟수를 줄이면 성능이 좋아질 수 있다.

 

CASE문의 횟수를 줄이는 방법은 CASE 처리하기 전에 고객별,주문년월별 주문금액을 먼저 집계하면 된다.

FROM (
	SELECT A.CUS_ID,SUBSTR(A.ORD_YMD,1,6), SUM(A.UNT_PRC * A.ORD_QTY) ORD_AMT
    FROM T_ORD_JOIN A
    GROUP BY A.CUS_ID, SUBSTR(A.ORD_YMD,1,6)
)T1

GROUP BY T1.CUS_ID
ORDER BY SUM(T1.ORD_AMT)DESC;

 

SQL을 개발하다 보면 CASE문이나 DECODE를 많이 사용하게 된다. 대량의 데이터를 처리할 때는

CASE나 DECODE의 위치에 따라 성능 차이가 날 수 있다. CASE를 적용할 대상을 줄일 방법이 있다면 

최대한 줄여주는 노력이 필요하다.

 

*조인도 마찬가지이다. 조인 후 조건으로 거르지말고, 조인 전에 조건으로 걸러진 테이블과 조인하는 편이 좋다. 

 

---

 

2. 집계 테이블을 고민해보자 

 

집계 테이블은 실적 테이블을 특정 수준으로 집계 해놓은 테이블이다.

 

집계 테이블의 장점

1. 계속 입력, 변경되는 실적 테이블에 접근하는 부담을 줄여준다.
2. 실적 데이터가 집계된 형태로 저장되므로, 데이터 건수가 줄어들어 조회 성능이 높아진다.

집계 테이블의 단점

 

• 관리 비용 증가
  
  • 집계를 수행하는 배치 작업과 배치를 실행할 스케줄을 생성해야한다. 
• 비실시간 데이터
  • 특정 시간 이전에 발생한 실적들을 모아서 집계하므로, 화면마다 데이터가 다를 수도 있다.
• 집계 과정의 오류 
  • 집계 중 오류가 발생할 수 있다. (집계 데이터 잘못 생성 혹은 생성 x)

집계 테이블은 위와 같은 장점과 단점을 모두 가지므로, 사용할 때 이모저모 따져보도록 하자