2. 처리 과정
2.2. 인덱스 (Index)
인덱스는 테이블의 데이터를 빠르게 접근하기 위한 색인 입니다.
인덱스 구성
- 하나 이상의 컬럼 + ROWID
- 인덱스를 구성하는 컬럼 값으로 정렬
- B-TREE 아키텍처로 구성
인덱스와 테이블 접근
- Rowid를 통해 빠르게 접근
SELECT name FROM emp WHERE rowid = 'AAAApDAACAAAABaAAA’;
- Where 절이 조건이 없어 table full scan
SELECT name FROM emp;
- Last_name 컬럼에 인덱스가 있으면 인덱스를 통해 테이블을 rowid로 접근
SELECT name FROM emp WHERE last_name = ‘KANG’;
인덱스 스캔
질의문에서 특정 조건에 만족하는 Row를 검색할 경우 조건과 일치하는 물리적인 Leaf 블록 내부
에서 일치하는 처음 위치를 찾습니다. 찾아진 위치는 논리적인 구조로 볼 때 리스트의 중간 특정
위치가 됩니다. 그 위치부터 아래 또는 위로 검색하는 것을 INDEX SCAN 이라고 하며, 이렇게
찾아진 결과인 Rowid에 의해 테이블의 랜덤 액세스가 일어나 원하는 결과를 가져옵니다.
Rowid
테이블에서 행의 위치를 지정하는 논리적인 값으로, 데이터 베이스 내부에 있는 자료의 저장
위치를 보여줍니다. 물리적 Rowid는 일반적인 테이블, 테이블 파티션, 인덱스, 인덱스 파티션에서
자료의 고유한 위치를 지정하기 위해서 사용됩니다.
| RowID: AAAJfZ ABAAAAAHeAAD | |||
| AAAJfZ | ABA | AAAAHe | AAD |
| 데이터 오브젝트 번호 | 데이터 파일번호 | 데이터 블록번호 | 블록 내부의 Row 번호 |
| 데이터 세그먼트를 나타내는 오브젝트 번호 입니다. |
테이블스페이스와 관련된 테이터 파일 번호로 유일한 값입니다. |
데이터파일과 관련된 데이터 블록번호 입니다. |
블록 내부 행의 위치 를 나타내는 번호로 0부터 시작합니다. |
인덱스 선정절차
- 프로그램 개발에 이용된 모든 테이블에 대하여 Access Path 조사
- 인덱스 칼럼 선정 및 분포도 조사
- Critical Access Path 결정 및 우선 순위 선정
- 인덱스 칼럼의 조합 및 순서 결정
- 시험 생성 및 테스트
- 결정된 인덱스를 기준으로 프로그램 반영
- 실제 적용
| 인덱스 선정 시 포함컬럼 | 인덱스 선정 시 불포함컬럼 |
|
|
인덱스와 성능관계
일반적으로는 인덱스를 통해 성능 향상을 가져오지만 적절하지 못한 인덱스는 성능을 저하
시킵니다.
인덱스를 많이 만들게 되면 인덱스를 통해 빠른 데이터 액세스가 가능합니다.
그러나 데이터가 추가/변경/삭제되는 경우 관련된 인덱스를 변경해야 하므로 오버헤드가 발생할
수 있습니다.
인덱스 사용 시 고려사항
- 새로 추가된 인덱스는 기존의 액세스 경로에 영향을 미칠 수 있습니다.
- 비용이 같은 같은 인덱스의 경우 나중에 생성된 것을 우선 참조합니다.
- 옵티마이저를 위한 통계 정보는 주기적으로 갱신해야 합니다.
- 인덱스의 개수는 테이블의 사용형태에 따라 적절히 생성해야 합니다.
지나치게 많은 인덱스 또는 넓은 범위를 인덱스로 처리 시 오버헤드가 발생합니다.
- 인덱스가 있더라도 사용하지 못하는 경우가 있으므로 주의합니다.
인덱스 사용 불가 상황
- 인덱스 컬럼에 변형이 일어난 경우
- 부정형으로 조건을 기술한 경우
- NULL로 비교하였을 경우
- 옵티마이저의 판단에 따라 (cost based optimizer)
- 내부적인 변형이 일어났을 경우
☞[Tibero]SQL Tuning (3)에서 계속됩니다.
'튜닝' 카테고리의 다른 글
| [Tibero] SQL Tuning (6) (0) | 2023.06.05 |
|---|---|
| [Tibero] SQL Tuning (5) (0) | 2023.06.01 |
| [Tibero] SQL Tuning (4) (0) | 2023.06.01 |
| [Tibero] SQL Tuning (3) (0) | 2023.05.31 |
| [Tibero] SQL Tuning (1) (0) | 2023.05.30 |