인덱스
데이터베이스에서 데이터에 접근할 때 특정 값을 찾기 위한 탐색이 비효율적일 수 있다. 예를 들어서 나이가 20살인 사람을 찾고자 하는데 데이터베이스 행 기준으로 탐색한다면 가장 마지막 행에 20살인 사람이 있을 때 모든 행을 탐색한 이후에야 해당 사람을 찾을 수 있을 것이다. 즉 시간복잡도가 $ O(n) $ 일 것이다.
그런데 탐색에서 효율적인 이진탐색이 존재하고, 삽입, 삭제가 좀 더 빠르게 가능한 여러 트리 자료구조가 있다. 이를 활용하면 원하는 값에 더 빠르게 접근할 수 있다. 이렇게 빠르게 원하는 값에 접근 가능하도록 만들어놓은 것을 색인, 즉 인덱스(index)라 한다.
테이블에서 한 개 이상의 속성을 이용하여 생성하며, B-트리 혹은 B+-트리를 이용해 구현한다. 두 경우 모드 순서대로 정렬된 속성과 데이터의 위치만을 보유하므로 테이블보다는 작은 공간을 차지한다. 저장된 값들은 테이블의 부분집합이 된다.
인덱스를 만들어두면 빠른 접근이 가능하다는 장점이 있지만, 아무래도 추가적인 공간을 사용해야 하고, 데이터를 삽입 및 삭제할 때 인덱스도 재구성해주어야 한다는 단점 역시 가지기 때문에 필요한 경우에만 인덱스를 만들어두고 사용하는 것이 권장된다.
MySQL에서는 실제로 값을 정렬하여 저장해두는 클러스터 인덱스(clusterd index)와 이를 보조하는 세컨더리 인덱스(secondary index)가 사용된다. 클러스터 인덱스는 기본적인 인덱스로 테이블 생성 시 기본키를 지정할 때 이 기본키에 대해 클러스터 인덱스를 생성한다. 기본키가 지정되어 있지 않다면 먼저 등장하는 UNIQUE
속성, 즉 보조키에 대해 클러스터 인덱스를 생성한다. 둘 다 없다면 행번호를 이용한다. 클러스터 인덱스 리프노드에는 물리적으로 실제 레코드가 존재하고, 테이블 당 하나만 존재할 수 있다.
세컨더리 인덱스는 크러스터 인덱스가 아닌 모든 인덱스를 말하며 세컨더리 인덱스의 레코드는 그 속성과 기본키 속성 값을 모두 가진다. 보조 인덱스를 검색하여 기본키 속성 값을 찾은 후 클러스터 인덱스로 가서 해당 레코드를 탐색하는 방식으로 동작한다.
앞서 언급했듯이 인덱스는 자주 사용되는 속성에 대해서만 설정하는 것이 권장된다. 즉 WHERE
절이나 JOIN
조건 등에 자주 사용되는 컬럼에 설정하는 것이 바람직하다. 하지만 인덱스를 너무 많이 생성하면 쓰기 성능이 저하될 수 있으므로 주의해야 하고, 함수나 가공 연산이 적용된 컬럼은 인덱스를 제대로 활용하지 못할 수 있어 사용하지 않는 것이 좋다. 인덱스는 일반적으로 선택도가 높은 속성, 즉 가능한 값이 다양하고 중복이 적은 속성에서 효과적이다.
'Computer Science and Engineering > Database' 카테고리의 다른 글
[DB] 정규화(normalization) 및 정규형(NF, normal form) 단계 (0) | 2025.06.02 |
---|---|
[DB] 이상 현상(anomaly) 및 함수적 종속성(FD, functional dependency) (0) | 2025.06.02 |
[DB] B-트리(B-tree) (0) | 2025.06.02 |
[DB] E-R 모델 및 릴레이션 변환 규칙을 이용한 데이터베이스 설계 (0) | 2025.05.20 |
[DB] 관계 데이터 연산(relational data operator) (0) | 2025.04.03 |