1. 인덱스의 필요성

DB에 저장된 자료를 더욱 빠르게 조회하기 위해 인덱스를 생성하여 사용함.
일반적으로, 인덱스는 테이블의 전체 데이터 중에서 일반적인 경우, 10~15% 이하의 데이터를 처리하는 경우에 효율적이며 그 이상의 데이터를 처리할 땐 인덱스를 사용하지 않는 것이 더 좋다. 

(테이블마다 저장된 데이터의 수가 다르므로 그 기준은 절대적이진 않다.)

 


2.  B* Tree(Balanced Tree)구조

 

출처 : http://www.btechsmartclass.com/data_structures/b-trees.html


가장 많이 사용되는 인덱스의 구조이며, 인덱스의 데이터 저장 방식이기도 함

- Root(기준) / Branch(중간) / Leaf(말단) Node로 구성됨
- Branch 노드는 Leaf 노드에 연결되어 있으며, 조회하려는 값이 있는 Leaf 노드까지 도달하기 위해 비교/분기해야 될 값들이 저장됨.
- 찾는 데이터는 Leaf 노드에 저장됨.

Leaf 노드 = 인덱스 칼럼의 값(오름(내림)차순으로 Sort되어 저장됨) + ROWID (테이블에 있는 해당 row를 찾기 위해 사용되는 논리적인(저장위치) 정보)

B*Tree 구조의 핵심은 Sort
- Order by에 의한 Sort를 피할 수 없음. (memory 소비가 줄어든다.)
- MAX/MIN의 효율적인 처리가 가능함. (미리 sorting 되어 있으므로)

 


3. 인덱스 선정 절차

1) 프로그램 개발에 이용된 모든 테이블에 대하여 Access Path 조사
2) 인덱스 칼럼 선정 및 분포도 조사
3) Critical Access Path(자주 수행되는 경로) 결정 및 우선 순위 결정
4) 인덱스 칼럼의 조합 및 순서 결정
5) 시험 생성 및 테스트
6) 결정된 인덱스를 기준으로 프로그램 반영
7) 실제 적용

 


4. 인덱스 생성 및 변경 시 고려할 사항 

- 기존 프로그램에 미치는 영향도 검토
- 필요할 때 마다 인덱스 생성으로 인한 인덱스 개수의 증가와 이로 인한 DML 작업의 속도가 지연될 수 있음.
- 비록 개별 칼럼의 분포도가 좋지 않을지라도 다른 칼럼과 결합하여 자주 사용되고, 결합할 경우에 분포도가 양호하다면 결합 인덱스 생성을 긍정적으로 검토

 


5. 인덱스 스캔의 원리

OPTIMIZER가 인덱스 사용을 위한 실행계획을 아래와 같이 수립한다.
1) 조건을 만족하는 최초의 인덱스 row를 찾음
2) Access 된 인덱스 row의 ROWID를 이용해서 테이블에 있는 row를 찾음 (Random Access)
3) 처리 범위가 끝날 때까지 차례대로 다음 인덱스 row를 찾으면서(Scan) 2)를 반복함.

인덱스 스캔시에는 한 번의 I/O가 발생할 때 마다 하나의 Block을 처리함.


'IT > SQL' 카테고리의 다른 글

Nested Loop Join  (0) 2023.07.24
인덱스 활용이 불가능한 경우  (0) 2023.07.23
결합 인덱스(Composite Index)  (0) 2023.07.19
옵티마이저(Optimizer)  (0) 2023.07.14
SQL 실행계획  (0) 2023.07.08

+ Recent posts