인덱스 (index)

 인덱스 (index) 

데이터베이스 분야에 있어서 테이블에 대한 동작의 속도를 높여주는 자료 구조를 일컫는다.

테이블 내의 1개의 컬럼, 혹은 여러 개의 컬럼을 이용하여 생성될 수 있다. 

고속의 검색 동작뿐만 아니라 레코드 접근과 관련 효율적인 순서 매김 동작에 대한 기초를 제공한다.

 

데이터베이스에 데이터를 요청할 때, 자주 쓰이는 데이터는 메모리에 저장된다.

그런데 메모리에 없다면 full table scan 을 통해서 데이터를 찾아야 한다.

데이터가 많다면 그건 정말 비효율 적이다.

 

이것을 막기 위해 인덱스를 통해서 자료를 정리하는 것이고,

인덱스는 메모리에 저장된다.

 

- 데이터 = 책

- 인덱스 = 책의 목차

- 물리적 주소 = 책의 페이지 번호

 

라고 생각할 수 있다.

 

 

 

출처 : 유튜브 [10분 테코톡] 🦋 레베카의 인덱스

인덱스의 구조에서 가장 많이 사용되는 구조는 B-tree 다.

출처 : 유튜브 [10분 테코톡] 🦋 레베카의 인덱스

 

인덱스의 운행 방식은 수직적으로 조건을 만족하는 첫 번째 레코드로 들어가서 

리프 노드에서 수평적으로 이동하여 찾게 된다.

 

 

 인덱스의 장점 

테이블을 검색하는 속도와 성능이 향상된다. 그에 따라 시스템의 전반적인 부하를 줄여준다.

 

인덱스에 의해 데이터들은 정렬된 형태를 갖게 되는데, 

기존에는 where 문으로 특정 조건의 데이터를 찾기 위해 full table scan 을 했어야 하는데,

인덱스를 이용하면 데이터드링 정렬되어 있기 떄문에 조건에 맞는 데이터를 빠르게 찾을 수 있다.

 

 인덱스는 항상 좋은가? 

인덱스는 항상 쓰는 것이 좋은 것은 아니다.

인덱스를 관리하기 위한 추가 작업이 필요하게 되고,

추가 저장 공간을 요구하며,

잘못 쓰는 경우 오히려 검색 성능을 저하시킬 수 있다.

 

select from where 할 때는 효율적이나

insert, update, delete 에서는 오히려 비효율적이라고 한다.

 

인덱스는 정렬이 된 상태로 저장이 되어야 하기 때문이다.

 

insert 를 하게 되면 어느 자리에 인서트를 할 지 찾아 저장을 하고 원래 있던 데이터를 뒤로 쭉 밀어줘야 하는데,

만일 저장할 블록이나 페이지가 꽉 차게 되면 뒤로 옮기면서 작업량이 더 많아진다.

 

또한 인덱스는 테이블과 별도의 객체라서

익덱스에도 삽입하고 테이블에도 삽입해줘야 하기 때문이다.

 

delete 는 실제로 삭제하는 것이 아니라

인덱스 안에는 사용안함 이라는 표시를 해두기 때문에 공간 낭비가 생길 수 있다.

 

 

update 의 경우 인덱스에는 업데이트라는 개념이 없기 때문에

테이블에 업데이트가 생기는 경우 인덱스에는 딜리트를 하고 인서트로 작업을 하기 때문에 

부하가 크게 걸린다.

만일 수정 작업이 많은 데이터라면 실제 데이터에 비해 인덱스가 과도하게 커지는 문제가 발생하게 된다.

인덱스는 벼롣의 메모리 공간에 저장되기 떄문에 추가 저장 공간을 더 요구하게 된다.

 

그 외에도 인덱스를 언제 잘 쓰는 것이 더 효율적인지에 대한 기준은 여러 가지가 있고,

상황에 따라 다른 부분이 많아서 상황과 조건에 따라 써야 한다.

 

 

참고로 인덱스 컬럼 설정 기준은 cardinality (기수성, 농도, 구성 요소의 수) 가 높은 것으로 잡는다.

 

 

 인덱스를 사용하면 좋은 경우 

 

데이터의 range가 넓고, 중복이 적고, 조회가 많거나 정렬된 상태가 유용한 컬럼에 사용한다.

 

- 규모가 큰 테이블

- insert, update, delete 등의 작업이 자주 발생하지 않는 경우

- where, order by, join 등이 자주 사용되는 컬럼

- 데이터의 중복도가 낮은 컬럼

 

 

 

참고)

https://rebro.kr/167

[DB] 11. 인덱스(Index) - (1) 개념, 장단점, B+Tree 등

 

https://www.youtube.com/watch?v=9ZXIoh9PtwY