DataBase/SQL

SQL BOOSTER - MERGE 조인과 성능

now0204 2024. 6. 24. 11:18

 

 

1. 대량의 데이터 처리 

 

머지 조인은 대량의 데이터를 조인할 때 적합하다. NL 조인과의 비교를 통해 머지 조인이 과연 대량 데이터 조인에 유리한지 살펴보자 

 

여기서는 머지 조인의 성능 테스트를 위해 T_ORD_BIG 테이블을 사용한다.

M_CUS와 T_ORD_BIG테이블을 NL조인하는 SQL이다. 

 

SELECT /*+ GATHER_PLAN_STATISTICS LEADING(T2) USE_NL(T1) FULL(T2) */
       T1.CUS_ID, MAX(T1.CUS_NM) CUS_NM, MAX(T1.CUS_GD) CUS_GD, COUNT(*) ORD_CNT
       ,SUM(T2.ORD_AMT) ORD_AMT
       ,SUM(SUM(T2.ORD_AMT)) OVER() TTL_ORD_AMT
FROM M_CUS T1, T_ORD_BIG T2
WHERE T1.CUS_ID = T2.CUS_ID
AND T2.ORD_YMD LIKE '201702%'
GROUP BY T1.CUS_ID;

 

SQL BOOSTER

 

SQL을 머지 조인으로 변경해 처리해보자. USE_MERGE 힌트를 사용한다. 

 

SQL BOOSTER

머지 조인으로 변경하자 5.57초로 성능이 개선되었다. 실행계획은 아래와 같다. Buffers 수치가 2.238K에서 258로 압도적으로 줄어들었다. 이로 실행 시간이 단축된 것이다.  

SQL BOOSTER

 

  1. PK_M_CUS 인덱스를 INDEX FULL SCAN
  2. 1번에서 찾은 ROWID를 이용해 M_CUS에 접근 (TABLE ACCESS BY INDEX ROWID)
  3. T_ORD_BIG을 TABLE ACCESS FULL, ORD_YMD가 201702%인 데이터를 검색
  4. 3번의 결과를 CUS_ID 순서로 정렬 처리 
  5. 2번을 처리하면서 4번의 결과와 머지 조인 처리한다. 

머지조인은 조인 개상을 미리 모아 놓고 한 번에 조인 처리한다. 대량의 데이터를 조인 처리할 때 효율적이다.

 


2. 필요한 인덱스 

 

머지 조인의 인덱스 전략을 알아보자. 머지 조인은 조인에 참여하는 데이터를 각각 조회해서 조인 처리한다.

그러므로 조인에 참여하는 테이블별로 대상을 줄일 수 있는 조건에 인덱스를 만들어 주면 된다.

 

A 테이블과 B 테이블이 머지 조인을 수행할 때 A와 B테이블 각각 WHERE 조건절이 있으면 각각 조건별로 인덱스를 구성해주면 된다. 단, 해당 조건에 인덱스를 사용하는 것이 TABLE ACCESS FULL보다는 좋은 성능을 낼 수 있어야 함

 

SELECT /*+ GATHER_PLAN_STATISTICS LEADING(T1) USE_MERGE(T2) FULL(T2) */
        T1.CUS_ID,MAX(T1.CUS_NM) CUS_NM, MAX(T1.CUS_GD) CUS_GD, COUMT(*) ORD_CNT, SUM(T2.ORD_AMT) ORD_AMT,
        SUM(SUM(T2.ORD_AMT)) OVER() TTL_ORD_AMT
        FROM M_CUS T1, T_ORD_BIG T2
        WHERE T1.CUS_ID = T2.CUS_ID
        AND T2.ORD_YMD BETWEEN '20170201' AND '20170210'
        GROUP BY T1.CUS_ID;

 

위 SQL은 20170201부터 20170210까지의 주문 데이터를 고객과 머지 조인한다. T_ORD_BIG테이블을 강제로 FULL SCAN하도록 FULL(T2) 힌트를 주었다. 

 

위 SQL을 머지 조인으로 유지 한 채 성능을 개선하려면, T_ORD_BIG의 ORD_YMD 컬럼에 인덱스를 고려해 볼 수 있다.

T_ORD_BIG에는 ORD_YMD가 포함된 인덱스가 이미 아래와 같이 있다. 

 

-X_T_ORD_BIG_1 : ORD_YMD

-X_T_ORD_BIG_3 : ORD_YMD,CUS_ID

-X_T_ORD_BIG_4 : CUS_ID, ORD_YMD,ORD_ST

 

SQL BOOSTER

 

각각의 실행계획에서 SORT JOIN 단계의 Bufferes와 Reads의 수치를 살펴보자. Reads항목은 세 경우 모두 비슷하다. 하지만 Bufferes 항목을 보면, X_T_ORD_BIG_1 인덱스를 사용한 경우가 압도적으로 좋다.

 

복합 인덱스인 X_T_ORD_BIG_3와 X_T_ORD_BIG_4는 머지 조인에서는 성능에 큰 도움이 되지 못하고 있다.

머지 조인을 항상 단일 인덱스로 사용해야한다고 결론 내리지는 말자! 항상 테스트를 해보고 결론을 도출하자 

 

복합 인덱스의 성능이 나쁘지 않으면, 복합 인덱스를 가져가는 것이 시스템 전체를 위해서 더 좋을 수도 있다.


참고자료

https://www.yes24.com/Product/Goods/82818767

 

SQL BOOSTER - 예스24

SQL BOOSTER는 프로젝트 성공을 위한 SQL 필독서다. 이 책은 마치 프로젝트를 진행하는 순서처럼 구성되어 있다. 프로젝트 투입을 위해 필요한 SQL 기술을 설명하고, 성능 테스트를 위해 필요한 기술

www.yes24.com