반응형
SMALL
인덱스 구성 할때의 컬럼 순서 결정 원리
- 두가지 선택 기준
1. 조건절에 항상 사용되거나, 자주 사용하는 컬럼을 사용
2. '=' 조건으로 자주 조회되는 컬럼들을 앞쪽에 둔다.
- 인덱스 설계는 공식이 아닌 전략과 선택의 문제
개별 쿼리기준으로 어떤 쿼리가 좋은지 명확히 구분할 수 있지만. 시스템 전체적인 관점에서의 효율은 또 다른 기준임
: 쿼리 수행 빈도, 업무상 중요도 , DML 부하, 저장공간, 관리비용
아래조건에 인덱스 설계해봅시다.
조건1) where 고객번호 = 1 and 거래일자 between '20010101' and '20111231' |
조건2) where 상품번호 = 'A' and 거래일자 between '20010101' and '20111231' |
조건3) where 고객번호 = 1 and 상품번호 = 'A' and 거래일자 between '20010101' and '20111231' |
조건4) where 거래일자 between '20010101' and '20111231' |
A | x1 : 고객번호 + 거래일자 x2 : 상품번호 + 거래일자 x3 : 상품번호 + 고객번호 + 거래일자 x4 : 거래일자 |
'=' 조건 컬럼을 모두 선두에 두고 모든 조건에 대해 인덱스 스캔 효율 극대화 시킨것. DML 부하와 관리비용에 조금 증가할 것이고 나중에 새로운 유형 도출되었을떄 이미 많아져 버린 인덱스 개수 때문에 고민스러울 수 있다. |
B | x1 : 고객번호 + 거래일자 x2 : 상품번호 + 거래일자 x3 : 거래일자 |
고객번호별 조회와 상품번호별 조회를 둘다 중요한 액세스 경로로 판단 조건3)일때 테이블 필터링 하긴 하지만 고객번호 변별력이 워낙 좋아 x1 인덱스를 사용함으로 테이블 액세스를 최소화 할 수 있다고 판단 범위가 긴 일자조건을 입력할 때는 상품번호 필터링 때문에 다소 비효율 생길수 있음 |
C | x1 : 고객번호 + 거래일자 + 상품번호 x2 : 상품번호 + 거래일자 x3 : 거래일자 |
조건3)일때 불필요한 테이블이 액세스가 발생하지 않도록 x1 인덱슷에 상품번호를 추가한 점이 다르다. 상품번호 인덱스가 필터역활만 하지만 선두컬럼 고객번호가 워낙 변별력이 좋아 인덱스 비효율은 아주 작을것으로 판단!! GOOD!! |
D | x1 : 고객번호 + 거래일자 x2 : 상품번호 + 거래일자 + 고객번호 |
B스타일과 같은전략.검색조건3일때 불필요한 테이블 액세스가 발생하지 않도록 하려고 x2인덱스에 고객번호를 추가한 점이 다른다.테이블 액세스를 최소하 할 수 있지만 상품번호의 선택도가 고객번호보다 높아서 스타일 C와 비교해 인덱스 스캔량이 더 많을 것 조건4)에 대한 고려가 없지만 일부러 Full Table 스캔을 유도하려는 것일 수도 있다. 또는 거래일자 기준으로 Range파티셔닝 전제로 한것일 수도 있다. |
E | x1 : 거래일자 + 상품번호 + 고객번호 x2 : 거래일자 + 고객번호 + 상품번호 |
between 조건을 최선두로 둔다면 나머지 조건은 거의 인덱스 필터 역활만 하므로 적어도 검색조건 1~4위해서라면 두중 하나는 제거해도 무방 그러면 J스타일과 같은 전략 |
F | x1 : 거래일자 + 고객번호 x2 : 거래일자 + 상품번호 |
검색조건 1~4위해서라면 효과적이지 못함 |
G | x1 : 거래일자 + 상품번호 x2 : 거래일자 + 상품번호 + 고객번호 |
상품번호 및 고객번호 검색조건에서도 인덱스 비효율이 발상함, 특히 변별력이 좋은 고객번호일때 비효율이 더 크게 발생 |
H | x1 : 고객번호 + 상품번호 + 거래일자 | 검색조건 2,4에 대한 대비가 없고 고객번호로 조회하는 1번에서도 인덱스 스캔 비효율이 발생함 |
I | x1 : 고객번호 + 거래일자 x2 : 거래일자 + 상품번호 + 고객번호 |
X2 인덱스 선두에 거래일자를 둬서 비효율은 발생하겠지만 항상 사용되는 컬럼이므로 모든 검색조건에 범용적으로 사용될 수 있음. 대신 사용빈도가 높고 변별력이 아주 좋은 고객번호가 조회조건에 포함될 때만이라도 x1인덱스를 효과적으로 이용하려는 의도가 보임 어떤 검색조건에서도 테이블 Random 액세스만큼은 최소화 할수 있어, 자주 입력되는 거래일자 범위가 아주 넓기 않다면 성능에 그다지 나쁘지 않다. 모든검색조건을 만족하면서 인덱스개수를 최소화했다는 측면에서 높이평가 |
J | x1 : 거래일자 + 상품번호 + 고객번호 | 인덱스 하나로 모든조건을 해결하려는 의도가 담긴것 같음. 인덱스 활용성이 높고 상황에 따라 문제 없이 잘 운영될 수도 있음. 근본적으로 비효율을 안고 있어 신중히 선택해야 할 설계방식 |
728x90
'SQL' 카테고리의 다른 글
SQL 조인 시 조건 ON과 WHERE 차이 (0) | 2022.06.21 |
---|---|
테이블 Prefech & 인덱스 Prefetch (0) | 2022.01.16 |
[그룹함수 / ROLLUP] (0) | 2021.12.29 |
[계층형 질의] (0) | 2021.12.21 |
집합 연산자 (SET OPERATOR) (0) | 2021.12.20 |