DB Index

Index 사용이유

• 조건을 만족하는 튜플을 빠르게 조회하기 위해
• 빠르게 정렬하거나 그룹핑하기 위해
• where뿐아니라 join의 on에도 인덱스 적용됨
• pk에는 index가 자동생성

인덱스가 생성된 컬럼은 O(longN)의 시간복잡도를 가짐. (B-tree)
인덱스 생성 안된 컬럼은 O(N)의 시간복잡도를 가짐.

1. 생성방법
   중복허용

create index index_name on table_name (column_name);

2가지 이상의 조건을 활용해 검색한다면 모두 인덱스를 생성해줘야된다.
중복허용x. unique 사용. => multi column index
and 조건은 2개 이상의 인덱스를 묵어 생성하면되지만 or 조건은 각각의 컬럼을 인덱스 생성해줘야한다.

create unique index index_name on table_name(column1, column2);

2. B-tree 기반 인덱스 동작 방법

members

a	b	c	d
10	4	2	1
2	4	2	1
3	4	2	1
9	4	2	1

index(a)

a	pointer
2	...
3	...
9	...
10	...

pointer는 members 테이블의 튜플 주소.
a=9인 튜플을 찾는다면 binary search를 수행.

만약 a=9 and b=3인 값을 찾는다면
a는 인덱스로 인해 빠르게 찾을 수 있지만 b값에 대해서는 a에 해당하는 튜플로 가서 b를 비교해 줘야한다.
이 경우 조건 2개에 해당하는 인덱스를 생성해줘야함.

index(a,b) => 정렬 조건은 왼쪽을 기준으로 정렬된다. => 만약 a 값을 기준으로 값을 찾는다면 빠르게 찾을 수 있지만 b 값만 이용해 찾는다면 a를 기준으로 정렬되있기 때문에 빠르게 찾을 수 없다.

a	b
2	4
3	3
9	2
9	3
9	4
10	1

3. index를 많이 만들어도 될까?

• 인덱스를 생서하게되면 별도의 인덱스 데이터가 생성되게 된다.

a	pointer
2	...
3	...
9	...
10	...

• table에 write할 때마다 index의 변경발생 (overhead)
• 추가적인 저장공간 차지

select name, phoneNo from members where name like "tom";

위의 쿼리문을 사용할 때
name, phoneNo에 multi column index가 생성되 있다면 인덱스만으로 결과조회 가능.
=> pointer로 실제 테이블의 튜플 데이터에 접근 안해도된다.
=> 더 빠른 검색속도.
=> covering index라고 한다.

4. Full scan이 더 좋은 경우

• table 데이터가 조금 일때.
• 조회 데이터가 테이블의 대부분을 차지할때
  => optimizer가 판단.