[DB] 인덱스 장점/단점

인덱스의 장점과 단점에 대해서 알아보겠습니다.

 

인덱스는 색인이라는 뜻으로 책의 목차와 같은 느낌으로 생각하시면 됩니다.

이와같이 해당 부분을 찾을때 보다 쉽게 찾을 수 있도록 도와주는 역할을 합니다.

 

이제 본격적으로 DB를 활용하여 인덱스의 장점과 단점에 대해 알아보도록 하겠습니다.

 

 

위의 DB를 보면 회원테이블이 있고, 그에대해 '이름 인덱스', '주소 인덱스', '연락처 인덱스'가 있습니다.

 

[장점]

먼저, 인덱스의 장점에 대해 알아보겠습니다.

위의 회원테이블에서 이름으로 조회(select)할시 이미 인덱스로 정렬되어있는 '이름 인덱스'를 활용하여 조회를 하게 됩니다.

정렬된 인덱스 데이터에서 해당 값의 주소값을 찾아 HDD(하드디스크)에서 주소값으로 해당값을 메모리로 끌어올리게됩니다.

때문에 회원테이블 전체에서 조회하는것 보다 실행 속도가 빠릅니다.

물론, '주소 인덱스', '연락처 인덱스' 각각에서도 마찬가지 입니다.

 

즉, 해당컬럼에서 데이터를 조회할때 인덱스가 있다면, 실행속도가 보다 빠릅니다. 

 

만약 인덱스가 존재하지 많은 컬럼에서 조회가 이뤄진다면, HDD에서 관련 블록을 모두 끌어올리게 되므로, 실행속도가 보다 느릴것입니다.

 

모든 컬럼에 인덱스를 만들어 놓으면 좋을거 같지만. 사실상 그렇지 않음을 아래에서 확인해 볼 수 있습니다.

왜냐하면, 테이블에서 조회(select)만 일어나는것이 아니기 때문입니다. 

DML시 무분별한 인덱스는 매우 비효율적일 수 있습니다.

 [단점]

이미 인덱스가 존재하는 컬럼에 데이터를 insert하게 되면, 인덱스의 정렬이 꺠지게 됩니다.

그렇기때문에 인덱스 분리 현상을 통해 데이터를 insert하게 됩니다.

나문희의 데이터를 넣기 위해 '이름 인덱스'를 반으로 분리하여 아래쪽을 새로운 블록으로 할당 한 후, 나문희가 들어갈 자리의 아래 레코드들을 밀고, 나문희 데이터를 삽입합니다. 이러한 과정을 인덱스 분리 현상이라고 부릅니다.

 

이번에는 delete를 알아보겠습니다. 

delete는 테이블에서는 해당 데이터가 지워지지만, 인덱스에서는 "사용안함" 체크만 됩니다.

그렇기때문에 삭제를 하더라고 인덱스에서는 용량이 변하지 않게 됩니다.

 

update또한 삭제 후 삽입이 되는 작업(DML)이므로 실행속도가 느려지게 됩니다.

 

결국, 인덱스가 많으면 많을 수록, DML 작업시 취약하게됩니다. 

 

==> 그러므로, 주기적으로 인덱스 리빌드작업을 해주어야합니다.

 

인덱스로 인해 실행시간으 느려짐을 확인하고 인덱스를 지우더라도, 쿼리의 실행계획이 미리 백업되어있다면,

인덱스를 지우더라도 실행시간이 줄어들지 않습니다. 

그리고 새로운 인덱스를 적용시켜 본 후 문제가 생기면 Stored Outline 프로시저 를 이용해 백업받아두었던 실행계획을 가져와야 합니다.

 

참고: https://multifrontgarden.tistory.com/11