일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- kopring
- 아펠가모 선릉
- git명령어
- 코틀린
- 스페인
- http상태코드
- elk
- 400에러
- Kotlin
- b-tree index
- sprintboot
- 스프링 AOP
- 세비야
- 바르셀로나
- 스페인 준비물
- 본식후기
- @Component
- 코틀린 함수
- 그라나다
- HTTP
- 아펠가모
- HTTP #웹기술
- db index
- 아펠가모선릉
- kotiln
- c# scv
- 관심지향프로그래밍
- Srping AOP
- 마드리드
- 코프링
- Today
- Total
끄적이는 메모장
[DB] Index란 본문
우리가 RDBMS에서 특정 값을 찾기 위해서는 순차적으로 탐색을 시도함 (Full Scan)
즉, 데이터가 많으면 많을수록 검색 시간이 증가하는 비효율이 발생을 함
Index란
- 테이블에 대한 검색 속도를 높여주는 자료구조를 말함
- 특정 값을 빠르게 찾기 위해 제공되는 기술
- 이를 위해 하나의 컬럼 혹은 여러 개의 컬럼을 인덱스로 생성 할 수 있음
예시) 아래와 같은 스키마의 데이터가 몇 만 건 있다고 가정해보자
- 인천에 사는 사람을 검색하고자 할 때 모든 데이터를 다 스캔해야 함(full scan)
번호 | 이름 | 지역 | 나이 | 전화번호 |
1 | 철수 | 서울 | 30 | xx-xox-xxx |
2 | 영희 | 서울 | 25 | xx-xxo-xxx |
3 | 은우 | 인천 | 29 | xx-xxx-oxx |
4 | 나래 | 인천 | 25 | xx-xxx-xox |
5 | 도현 | 경기 | 21 | xx-xxx-xx0 |
... | ||||
30000 | 소현 | 인천 | 31 | ox-xxx-xxx |
- 하지만 인덱스가 있는 경우 full scan 하지 않아도 중간의 데이터를 검색할 수 있음
예시) 지역이 index라면 Index-Key 필드만 가진 빠른 탐색을 가능하게 하는 테이블이 됨
서울 | 1 |
서울 | 2 |
인천 | 3 |
인천 | 4 |
인천 | 30000 |
경기 | 5 |
... |
- 이러한 인덱스를 저장하기 위해서는 별도의 공간이 필요함
- 보통 인덱스 B-Tree 자료구조를 이용
> Index가 정렬되어 있으며 root node와 branch node에 Index값이 존재하고 데이터를 찾기 위한 정보는 leaf node에 있음
Index를 생성해야 하는 경우
- 조건절에서 사용되는 컬럼 값을 인덱스로 구성
- 데이터의 중복이 많은 컬럼 값을 인덱스로 구성
(위의 예시로 나이로 인덱스를 했다면 모든 나이에 대한 인덱스가 생성되고 효율도 안좋을 것)
- 즉 Join에 자주 사용되는 컬럼 값이 인덱스로 구성하기 적합
- 데이터의 변경이 많은지 고려 (데이터 변경 보다 검색이 빈번한 경우 Index가 더 효율적)
- 데이터의 양이 별로 없다면 오히려 full scan이 빠를 수 있음을 주의
참고
'웹기술 개발자 되기 > DB기술' 카테고리의 다른 글
[DB] 데이터베이스 정규화 (0) | 2020.04.17 |
---|---|
[DB] 트랜잭션(Transaction) (0) | 2020.04.15 |
[DB] 파티셔닝(Partitioning) (0) | 2020.04.14 |