Index
추가적인 쓰기작업과 저장공간을 활용하여 RDBMS에서 검색 속도를 높일 수 있는 자료구조이다.
예를들어 책이라고 생각해보면,
책의 내용 = 데이터, 목차 = Index, 목차의 페이지 번호 = 데이터가 저장된 레코드 주소라고 할 수 있다.
따라서 모든 데이터를 검색해서 원하는 결과를 가져오는 시간보다 미리 저장해둔 값에 따른 위치로 접근하여 속도면에서 유리하다.
Index의 장단점
장점
CUD 작업(Insert, Update, Delete)은 기본적으로 R 작업(Select)을 선행하기 때문에 대부분의 작업에서 성능개선을 기대할 수 있다.
단점
추가적인 저장공간이 필요하다.
또한, 잘못된 사용이나 무분별한 사용으로 성능이 저하될 수 있다.
CRUD에 따른 성능 비교
CUD 작업(Insert, Update, Delete)은 기본적으로 R 작업(Select)을 선행하기 때문에 효율적인 인덱스 사용은 성능을 높여준다.
다만, 인덱스가 적용된 컬럼에 CUD 작업이 발생한다면 Overhead가 발생한다.
SELECT
해당 인덱스가 조건으로 들어가는 조회일 경우 속도가 빠르다.
INSERT
새로운 데이터가 추가되면서,
인덱스를 추가하기 위해 기존의 정렬되어있는 인덱스 중 저장 위치를 찾는 작업을 진행하기때문에 느릴 수 있다.
또한 테이블과 인덱스, 두군데에 저장해야하기 때문에 느리다.
UPDATE
사실 상 DELETE-INSERT 이기 때문에 부하가 있다.
DELETE
삭제되는 데이터에 대한 인덱스가 삭제되는 것이 아닌 사용 제외 처리 된다.
Index 설정 기준
카디널리티 (Cardinality)
컬럼에 사용되는 값의 다양성 정도를 나타내는 지표이다
특정 컬럼을 기준으로 중복도가 높으면 카디널리티가 낮고, 중복도가 낮으면 카디널리티가 높다고 한다
선택도 (Selectivity)
컬럼의 특정값의 row 수 / 테이블 총 row 수 * 100
5~10% 정도가 적당하다.
활용도
활용도가 높을 수록 좋다.
해당 컬럼이 조회 WHERE 절에 자주 활용되는지 판단하면 된다.
중복도
중복도가 없을 수록 좋다.
같은 컬럼에 대해 인덱스가 중복으로 생성되는 경우 인덱스 설정으로 인한 속성 데이터 등이 추가적으로 생기기 때문에 메모리적 측면에서 좋지 않다.
Index를 사용해도 성능이 좋지 않은 경우
- 인덱스 컬럼을 가공하는 경우
- SUBSTR, DECODE ...
- 인덱스 컬럼의 묵시적 형변환
- DATE 형을 STRING과 비교
- 인덱스 컬럼 부정형 비교
- != 연산자 사용
- LIKE 연산자 사용 시 %가 앞에 위치하는 경우
- OR 조건 사용 → UNION ALL로 대체
'CS > DB' 카테고리의 다른 글
DB 트랜잭션 & 트랜잭션 격리수준 (0) | 2023.03.14 |
---|---|
[DB] Index with B-Tree (0) | 2021.06.28 |