본문 바로가기

CS/DB

Index ( 인덱스 )

RDBMS에서 검색 속도를 높이기 위한 기술

데이터베이스에서 조회 및 검색을 더 빠르게 할 수 있는 방법/기술 혹은 이에 쓰이는 자료구조 자체를 의미하기도 한다.

 

 

자주 조회되는 Column 에 대한 Index Table 을 따로 만들어 SELECT 문이 들어왔을 때, Index 테이블에 있는 값들로 결과 값을

조회해 온다. 그래서 Index를 잘 사용한다면 "검색" 연산을 실행했을 때, 성능을 올릴 수 있게 된다.

 

 

테이블의 칼럼을 색인화한다.

( 마치 두꺼운 책의 목차와 같다고 생각하면 편하다. )

 

데이터베이스 안의 레코드를 처음부터 풀스캔하지 않고, B+ Tree로 구성된 구조에서 Index 파일 검색으로 속도를 향상시키는 기술

 

 

 

B+ 트리 알고리즘

리프 노드에는 실제 데이터가 저장된다.

리프노드까지의 경로 역할을 하는 논리프 노드.

경로의 출발점이 되는 루트 노드

 

B+ 트리는 리프노드에 이르기까지에 대한 자식 노드에 포인터가 저장되어 있다. 즉 B+트리의 검색은 루트노드에서 어떤 리프

노드에 이르는 한 개의 경로만 검색하면 되므로 매우 효율적이다.

 

 

B+ 트리를 왜 사용할까? Hash table이 더 효율적이지 않나?

SELECT 질의 조건에는 부등호 연산도 포함되어 있다.

Hash table 은 동등 연산에 특화된 자료구조이기 때문에 부등호 연산 사용시 문제가 발생한다.

 

파일 구성

테이블 생성 시, 3가지 파일이 생성된다.

 

- FRM : 테이블 구조 저장 파일

- MYD : 실제 데이터 파일

- MYI : Index 정보 파일 ( index 사용시 생성 )

 

 

단점 

- index 생성 시, mdb 파일 크기가 증가한다.

- 한 페이지를 동시에 수정할 수 있는 병행성이 줄어든다.

- 인덱스 된 Field 에서 data를 업데이트하거나, Record를 추가 또는 삭제시 성능이 떨어진다.

- 데이터 변경 작업이 자주 일어나는 경우, Index를 재작성해야 하므로 성능에 영향을 미친다.

- 인덱스는 이진트리를 이용하기 때문에, 기본적으로 정렬되어 있다. 이로인해 검색과 조회의 속도를 향상시킬 수 있지만 

잦은 데이터의 변경이 일어나면, 인덱스 테이블을 변경하는 것과 정렬함에 따른 오버헤드 때문에 오히려 성능 저하가 생길 수 있다.

 

 

쓰면 좋을 때

- Where 절에서 자주 사용되는 Column

- 외래키가 사용되는 Column

- Join 에 자주 사용되는 Column

 

피해야 할 때

- Data 중복도가 높은 Column

- DML 이 자주 일어나는 Column

 

 

DML이 일어날 때 상황

 

'CS > DB' 카테고리의 다른 글

Transaction ( 트랜잭션 )  (0) 2021.04.15
SQL vs NoSQL  (0) 2021.04.15
Join  (0) 2021.04.15
Key  (0) 2021.04.15
UML ( Unified Modeling Language )  (0) 2021.04.14