인덱스
- 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조
- SELECT 뿐만 아니라 UPDATE나 DELETE의 성능도 향상된다.
- 해당 대상을 조회해야 작업을 할 수 있기 때문
- 인덱스는 항상 최신의 정렬 상태로 유지해야 하기 때문에, INSERT / UPDATE / DELETE가 자주 수행된다면 오버헤드가 많이 발생할 수 있다.
- 인덱스의 장단점
- 장점
- 테이블을 조회하는 속도와 그에 따른 성능을 향상시킬 수 있다.
- 단점
- 인덱스를 관리하기 위해 DB의 약 10%에 해당하는 저장 공간 필요
- 인덱스 관리를 위한 추가 작업 필요
- 인덱스를 잘못 사용할 경우, 오버헤드에 의한 성능 저하 역효과가 발생할 수 있다.
UPDATE와 DELETE의 인덱스 관리
UPDATE는 기존 인덱스를 사용 안함 처리하고, 갱신된 데이터에 대해 인덱스를 추가한다.
DELETE는 삭제하는 데이터의 인덱스를 사용하지 않는다는 작업을 진행한다.
⇒ 따라서 빈번한 UPDATE와 DELETE는 인덱스를 비대하게 만들어, 성능 저하가 될 수 있으니 잘 고려해서 사용해야 한다.
- 인덱스를 사용하면 좋은 경우
- 규모가 작지 않은 테이블
- INSERT, UPDATE, DELETE가 빈번하지 않는 컬럼
- JOIN이나 WHERE, ORDER BY에 자주 사용되는 컬럼
- 데이터 중복도가 낮은 컬럼
인덱스의 자료구조
- B+ tree
- B-Tree의 확장
- B-Tree : 하나의 노드가 가질 수 있는 자식 노드의 최대 숫자가 2보다 큰 트리 구조
- 리프노드에만 인덱스와 함께 데이터를 가지고 있으며
- 리프노드들이 LinkedList로 연결되어 있다.

- 해시 테이블
- (Key, Value)로 데이터 저장, 빠른 데이터 검색이 필요할 때 유용
- 시간 복잡도가 O(1)로 매우 빠른 검색을 지원
- 하지만 해시의 특성상 값이 1만 달라져도 완전히 다른 해시를 생성하기 때문에,
- 부등호 연산(<, >)이 자주 사용되는 데이터베이스 검색을 위해서는 해시 테이블이 적합하지 않다.

- 클러스터 인덱스
- 물리적으로 행을 재배열한다.
- 검색 속도는 더 빠르지만 데이터의 입력, 수정, 삭제는 느림
- 비클러스터드 인덱스
func (user) Indexes() []ent.Index {
return []ent.Index{
// non-unique index.
index.Fields("created"),
index.Fields("ca_name"),
index.Fields("user"),
// unique index
index.Fields("id", "ca_name").Unique(),
}
}
Share article