성능 개선

clustered index

클러스터드 인덱스 순서로 레코드들이 하드디스크에 저장된다. 클러스터드 인덱스를 따로 지정하지 않으면, 기본 키(primary key)가 클러스터드 인덱스가 된다.

클러스터드 인덱스를 만들면, 조회할 레코드들이 하드디스크에서 서로 모여있기 때문에, 최소한의 하드디스크 읽기로 게시글 목록을 조회할 수 있다. 그리고 조회할 순서대로 레코드들이 저장되어 있기 때문에 하드디스크에서 순서대로 레코드를 읽을 수 있다. 따라서 읽어야할 데이터가 하드디스크에 순서대로 모여있으면 헤드 이동 없이 한 번에 읽을 수 있으므로 빠르다.

 

장점은 테이블의 모든 보조 인덱스가 클러스터링 인덱스를 가지고 있기 때문에 인덱스만으로 처리될 수 있는 경우가 많다(이를 커버링 인덱스라고 함)

단점은 테이블의 모든 보조 인덱스가 클러스터 키를 갖기 때문에 클러스터 키값의 크기가 클 경우 전체적으로 인덱스의 크기가 커진다. 또한 프라이머리 키를 변경할 때 레코드를 DELETE하고 INSERT하는 작업이 필요하기 때문에 처리 성능이 느리다.

 

clustered index vs nonclustered index

클러스터링 인덱스 구조를 보면 클러스터링 테이블의 구조 자체는 일반 B-Tree와 많이 비슷하게 닮아 있다. B-Tree의 리프 노드는 인덱스 필드 값과 레코드 주소가 저장됐다. 하지만 클러스터링 인덱스의 리프 노드에는 레코드의 모든 컬럼이 같이 저장되어 있다.

 

DB Index

데이터베이스 엔진이 테이블을 조회할 때, 빠르게 레코드를 찾기 위해, 그 테이블의 인덱스(index)를 활용한다.

그리고 조회 결과 레코드 순서를 정렬할 때에도 인덱스를 활용한다. (ORDER BY)

데이터베이스 인덱스는 대부분 B-트리 자료구조로 구현된다.

그렇지만 인덱스를 너무 많이 만드는 것도 바람직하지 않다.

• 디스크 공간 차지
• 레코드를 INSERT/UPDATE/DELETE 할 때 마다 인덱스도 수정해야 함