티스토리 뷰
Clustering Factor
- 데이터가 모여 있는 정도를 수치로 보여주는 것
- 데이터 분포도에 따라서 데이터 블록에 접근하는 횟수가 달라지기 때문에 성능 측면에서 중요한 요소이다.
- 클러스터링 펙터 출력 쿼리
SELECT
T.TABLE_NAME,
I.INDEX_NAME,
T.BLOCKS,
T.NUM_ROWS,
I.CLUSTERING_FACTOR
FROM USER_TABLES T, USER_INDEXES I
WHERE I.TABLE_NAME = T.TABLE_NAME
AND T.TABLE_NAME IN ('ORD_ITEM', 'ORD_ITEM_RANDOM');
- 클러스터링 팩터는 테이블 자체로는 좋다 나쁘다고 할 수 없다. 특정 인덱스를 이용할 때, 해당 인덱스으 클러스터링 팩터가 좋은지 나쁜지를 말할 수 있다.
- 클러스터링 팩터의 값이 블록 수에 가까우면 좋은 것이고, 로우 수에 가까우면 나쁜 것이다.
기존 인덱스에 컬럼 추가하기
아래와 같은 테이블과 인덱스 구성이 있다고 가정하자.
- 테이블
- 상품 ID(PK)
- 상품명
- 상품구분코드
- 판매여부
- 인덱스
- 상품구분코드
- 상품명
위와 같은 인덱스를 사용하여
SELECT * FROM 상품 WHERE 상품구분코드 = '100101' AND 판매여부 = 'Y';
쿼리를 날리면
1. 상품 구분 코드 인덱스를 스캔하고 상품 구분 코드가 100101인 데이터를 모두 테이블에서 랜덤 엑세스 한 뒤, 판매여부가 조건에 맞는 데이터를 찾는다.
2. 조건으로 붙이는 상품구분코드 + 판매여부 순서로 된 인덱스를 추가하면 가장 좋겠지만 이런 식으로 인덱스를 추가하면 추후에 다른 조건으로 select를 수행할 때마다 비슷한 식으로 인덱스를 추가해야 한다.
3. 이런 상황에서는 기존 인덱스의 맨 뒤에 판매여부 칼럼을 추가하여 사용해야 한다.
4. 인덱스의 용량은 증가하겠지만, 테이블로의 래덤 엑세스는 최종 결과 집합에 해당하는 데이터만큼만 엑세스 하기 때문에 성능면에서 좋은 효과를 볼 수 있다.
다른 경우로 ORD_X01 => ORD_DT + ORD_HMS가 있고
SELECT
COUNT(UPPER_CASE)
FROM ORD
WHERE ORD_DT BETWEEN '20120101' AND '20120228'
AND SHOP_NO = 'SH0001';
위 쿼리를 날렸을 때, SHOP_NO가 인덱스에 없는 칼럼이기 때문에 테이블의 모든 데이터에 엑세스하여
SHOP_NO = 'SH0001' 조건을 처리하여 6213건을 최종 집합으로 만든다.
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 32551 (100)| |
| 1 | SORT AGGREGATE | | 1 | 27 | | |
|* 2 | TABLE ACCESS BY INDEX ROWID BATCHED| ORD | 6213 | 163K| 32551 (1)| 00:00:02 |
|* 3 | INDEX RANGE SCAN | ORD_X01 | 1251K| | 4692 (1)| 00:00:01 |
-------------------------------------------------------------------------------------------------
즉, 125만 건 이상의 INDEX RANGE SCAN이 불필요한 것이다.
이럴 때도 기존 인덱스에 SHOP_NO 컬럼을 추가하면 SHOP_NO만 가지는 새 인덱스를 추가하는 것 보다 효율적이다. (새 인덱스를 스캔하는 시간을 줄이기 때문에)
DROP INDEX ORD_X01;
CREATE INDEX ORD_X01 ON ORD(ORD_DT, ORD_HMS, ORD_NO);
이제 동일한 쿼리를 날려보면
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1080 (100)| |
| 1 | SORT AGGREGATE | | 1 | 27 | | |
| 2 | TABLE ACCESS BY INDEX ROWID BATCHED| ORD | 6213 | 163K| 1080 (1)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | ORD_X01 | 6213 | | 915 (1)| 00:00:01 |
-------------------------------------------------------------------------------------------------
랜덤 액세스 횟수가 비약적으로 감소하는 것을 확인할 수 있다.
PK 인덱스 확장하기
PK 인덱스를 변경할 때 주의할 사항은 기존 PK 컬럼들을 선두에 놓아야 한다는 것이다.
PK 인덱스의 변경 처리는 아래와 같다.
CREATE TABLE ITEM (
ITEM_ID NUMBER(10),
ITEM_NM VARCHAR2(100),
ITEM_TYPE_CD VARCHAR2(6),
SALE_YN VARCHAr2(1),
...
);
CREATE INDEX ITEM_PK ON ITEM(ITEM_ID, ITEM_NM);
ALTER TABLE ITEM ADD CONSTRAINT ITEM_PK PRIMARY KEY (ITEM_ID) USING INDEX ITEM_PK;
인덱스 스캔 범위 계산
SELECT * FROM 상품 WHERE 상품명 = '불고기버거' AND 상품구분코드 BETWEEN '100100' AND '100101';
위 쿼리가 있을 때,
INDEX01(상품구분코드, 상품명)과 INDEX02(상품명, 상품구분코드)를 사용한 스캔의 범위는 분명한 차이가 난다.
1번은 상품구분코드의 범위를 다 읽으면서 불고기 버거를 필터링하는 방식이고,
2번은 = 조건이 먼저 있어서 상품명을 인덱스 시작지점으로 찾은 후에 상품코드를 찾게 된다.
CREATE INDEX ORD_X02 ON ORD(ORD_DT, SHOP_NO);
CREATE INDEX ORD_X03 ON ORD(SHOP_NO, ORD_DT);
SELECT /*+ INDEX(ORD_X02) */
*
FROM ORD
WHERE ORD_DT BETWEEN '20120101' AND '20120131'
AND SHOP_NO = 'SH0001';
------------------------------------------------------------------------------------------------
| Id | Operation | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 280 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| ORD | 305 | 47275 | 280 (1)| 00:00:01 |
|* 2 | INDEX SKIP SCAN | ORD_X02 | 305 | | 6 (17)| 00:00:01 |
------------------------------------------------------------------------------------------------
SELECT
*
FROM ORD
WHERE ORD_DT BETWEEN '20120101' AND '20120131'
AND SHOP_NO = 'SH0001';
------------------------------------------------------------------------------------------------
| Id | Operation | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 278 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| ORD | 305 | 47275 | 278 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | ORD_X03 | 305 | | 4 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------
'Database' 카테고리의 다른 글
[Oracle Tunning] Join (1) | 2024.08.28 |
---|---|
[Oracle Tunning] INDEX Scan 방식 (0) | 2024.08.28 |
[Oracle Tunning] INDEX 기본 (1) | 2024.08.28 |
[Oracle Tunning] DBMS_XPLAN.DISPLAY_CURSOR (0) | 2024.08.28 |
[Oracle Tunning] 오라클 아키텍쳐 (0) | 2024.08.28 |
- AsyncStorage
- redux
- Promise
- redux-thunk
- react
- 파니노구스토
- 인천 구월동 이탈리안 맛집
- Async
- 맛집
- 이탈리안 레스토랑
- react-native
- 정보보안기사 #실기 #정리
- await
- javascript
- 인천 구월동 맛집
- Total
- Today
- Yesterday