Index | Atelier

type

status

date

slug

summary

정의

데이터베이스의 검색 속도를 향상시키기 위한 자료구조

단건 조회로 아래의 쿼리문을 작성한다고 해보자

id	name	address	category
1	Restaurant A	Address A	Category A
2	Restaurant B	Address B	Category B
3	Restaurant C	Address C	Category C
4	Restaurant D	Address D	Category D
5	Restaurant E	Address E	Category E
6	Restaurant F	Address F	Category F
7	Restaurant G	Address G	Category G
8	Restaurant H	Address H	Category H
9	Restaurant I	Address I	Category I
10	Restaurant J	Address J	Category J

해당되는 쿼리가 N 번째 존재하게 된다면 성능저하가 발생할 수 있다.

Hash Table - INNODB 엔진에는 없음

key-value 를 한 쌍으로 데이터를 저장하는 구조

부가적인 정보 작성하겠음.

B-tree

하나의 노드에 여러 정보 저장 가능

두개 이상의 자식을 가질 수 있음

leaf 노드에만 데이터 저장, 나머지 노드는 자식포인터만 저장

쓰기 느림(삽입, 수정), 검색 빠름

인덱스를 사용하면 이렇게 빨라짐

종류

Clustered index

실제 데이터와 군집(강한 연관을 이루는 인덱스)
데이터가 테이블에 물리적으로 저장되는 순서를 정의

PK로 설정하면 자동으로 생성

또는 Unique and Not null 제약 조건을 생성함

특징

해당 키 값을 기반으로 테이블이나 뷰의 데이터 행을 정렬하고 저장함

Index의 리프 페이지가 실제 데이터

테이블 당 1개만 존재

Non-clustered Index

Index 생성 SQL → CREATE INDEX name_idx ON restaurant(name) 또는 Unique 제약 조건을 생성

특징

인덱스와 데이터 페이지가 따로 존재

리프페이지에서는 데이터주소를 가짐

데이터페이지가 정렬되지 않아도 됨

한 테이블에 여러개가 존재할 수 있음

데이터 변경작업(삽입, 삭제, 수정)시 오버헤드가 발생할 수 있음

Clustered, Non-clustered 동시에 존재하면?

PK 칼럼을 설정하여 테이블을 생성한 뒤(clustered index),

자주 발생하는 조회 column에 대해 index를 추가한다면(Non-clustered index)

어떻게 동작할까?

어떤 경우에 쓰면 좋을까?

클러스터 인덱스

키 값의 범위 기반으로 하는 검색이나 정렬된 데이터가 필요한 경우

논 클러스터 인덱스

여러 개의 칼럼을 자주 검색하는 경우

어떻게 인덱스를 쓰면 좋을까?

where, join 조건에 자주 발생하는 칼럼들

INSERT, UPDATE, DELETE 적게 발생하는 칼럼

중복도가 낮은 칼럼

범위 검색이 적은 칼럼

데이터가 많은 테이블

더 알면 좋은 것들

covering index

cardinality

다양한 index scan 방식

page/block 및 버퍼

메모리, 디스크 I/O 접근 방식

B-tree