RDBMS - 인덱스 | dev-marco-song

RDBMS - 인덱스

인덱스는 우리말로 색인과 같은 개념이다.

색인의 사전적 정의는 다음과 같다. 색인 : 책속의내용중에서중요한단어나항목**,인명따위를쉽게찾아볼수있도록일정한순서에따라별도로배열하여놓은목록.**

우리는 원하는 정보가 있을 때 목차나 색인을 보고 해당 정보가 있는 페이지를 바로 찾을 수 있다. 인덱스가 없다면 어떤 단어를 찾을 때, 책의 첫 페이지부터 끝 페이지까지 순서대로 검색해야 한다.

DB에서의 인덱스는? DB의 내용 중에서 필요한 데이터를 쉽게 찾을 수 있도록 일정한 순서에 따라 배열한 목록이 되겠다.

인덱스를 사용하는 이유는 검색 속도를 높이기 위함이다.

1) 검색이 빨라진다. (SELECT, WHERE 절로 검색해야할 때 성능 향상) 인덱스가 없다면 테이블 전체를 key 순서대로 순차 탐색해야 한다.

1) 인덱스를 담아놓기 위한 추가 테이블 필요 -> 공간 더 사용

2) 인덱스 생성 및 수정에 대한 오버헤드 존재

3) 삽입 / 수정 / 삭제 성능이 하락할 수 있음(INSERT, UPDATE, DELETE)

원인 : 인덱스는 B tree 자료 구조로 구현하는데, 인덱스에 들어간 key가 바뀌면 B 트리의 균형이 깨지면서 B 트리 구조를 수정해야 할 경우가 생긴다. -> 추가적인 I/O. 성능 하락

삽입 / 삭제 : 데이터를 삽입/삭제하면서 B트리 균형 깨짐 -> B 트리 구조 수정 수정 : B 트리에서의 수정은 삭제+삽입으로 구현한다. 인덱스의 순서를 유지해야 하기 때문이다.

따라서 SELECT 쿼리를 많이 사용하며, INSERT / UPDATE / DELETE를 적게 사용한다면 인덱스 사용을 고려해봐야 한다.

데이터를 빨리 찾기 위한 방법임에 유의.

1) 클러스터드 인덱스

테이블 당 한 개만 생성 가능하며, 행 데이터를 인덱스로 지정한 컬럼에 맞춰 정렬시킨다. (보통 PK)

데이터 INSERT / DELETE 마다 행 정렬이 일어나므로, 이들 쿼리를 자주 할 경우 성능 저하

‘정렬’을 한다는 것에 유의

2) 넌-클러스터드 인덱스

테이블 당 여러 컬럼에 대해 생성 가능

별도의 공간에 인덱스 테이블을 생성하여, 정렬 효과를 구현.

글로만 보면 어려울 수 있으니 아래 블로그 자료를 참고하자. 그림과 함께 잘 설명돼 있다. http://lng1982.tistory.com/144

두 인덱스의 차이점은, 데이터의 순서를 어떻게 구현할 것인가에서 나타난다.

클러스터드 인덱스는 데이터를 직접 정렬해서 순서를 구현하고, 넌-클러스터드 인덱스는 별도의 인덱스 테이블을 순서대로 만들어 정렬한 효과를 만든다.

아! 그렇다면 비슷한 데이터를 여러 개 가져온다고 하면 클러스터드 인덱스가 유리하겠네! 걔네들 데이터는 모두 인접한 곳에 위치해 있기 때문 - HDD로 구성된 DB라면 이 인덱스가 유리하겠군

만약 1~100까지의 pk를 가진 DB에서 50 이하의 데이터들을 추출해온다면?

클러스터드 인덱스에서는 순서대로 1~50을 가져오겠지만, 넌-클러스터드 인덱스에서는 인덱스 테이블을 참조해서 일일이 데이터를 찾아가야 한다 -> SELECT 성능이 떨어질 수 있음 (1은 한양에, 2는 부산에..)

B트리 자료구조 인덱스의 근간인 B 트리 자료구조는 컴퓨터 공학에서 배운다. 꽤나 복잡한 과정이지만 한 번쯤 봐두면 좋다. http://slideplayer.com/slide/10051339/ https://www.slideshare.net/kuldeep100/b-trees-dbms

땡! UPDATE 를 해도, 인덱싱된 키값이 변경되지 않는다면 UPDATE에 영향을 주지 않는다. (ex : 인덱싱된 회원 테이블에서, 인덱싱된 키 값 변경 없이, 해당 데이터의 다른 컬럼(전화번호, 닉네임 등)을 수정할 경우) https://dba.stackexchange.com/questions/125300/effect-of-an-index-on-update-statements-where-update-column-is-not-in-an-index