[DB] 인덱스 간략 정리 [1]

인덱스

랜덤 & 순차 IO

디스크 헤더를 1번, 여러번 옮기느냐? 즉, 디스크의 성능은 디스크 헤더 위치 이동 없이 얼마나 많은 데이터를 한 번에 기록하느냐에 따라 결정

Mysql 는 그룹 커밋, 바이너리 로그 버퍼, InnoDB 로그 버퍼 등의 기능으로 개선

결국 랜덤 IO 를 줄이는 것이 쿼리를 개선하는 것을 의미

정의

ArrayList 와 SortedList 의 차이를 아는가?

순차적으로 저장 or 정렬하여 저장

빠르게 적재 or 느리지만 정렬하여 적재

인덱스를 적용한다는 것은 쓰기 성능을 어느 정도 포기하고, 읽기 성능을 택하겠다.

B-Tree 에서 인덱스 키 추가 및 삭제 시

보통의 경우, 레코드 추가 비용 1 가정 시 인덱스 추가 비용을 1.5 로 예측하는 편.

인덱스 키 삭제와 변경의 경우, InnoDB 엔진에 버퍼 되어, 지연 처리가 가능하다.

키 값 변경은 키 값 삭제 → 새로운 키 추가 순서로 이루어진다. → 역시 InnoDB 체인지 버퍼로 지연 처리

인덱스 키 값의 크기

인덱스를 구성하는 키 값의 크기가 커지면, 디스크 IO 횟수가 늘어나고, 느려진다.

→ 전체적인 인덱스의 크기가 커진다

→ InnoDB 의 버퍼 풀은 크기가 제한적이므로 메모리에 캐시 가능한 레코드 수가 줄어든다.

→ 메모리 효율이 떨어짐.

읽기

인덱스를 통해 읽을 레코드의 건수가 전체 테이블 레코드의 20~25% 를 넘을 경우, 테이블을 직접 모두 읽는 것이 효율적

→ 일반적인 DBMS 의 옵티마이저는 인덱스를 통해 1건을 읽는 것이 직접 레코드 1건을 읽는 것보다 4~5배 비용이 많이드는 작업

다중 칼럼 인덱스

복합 인덱스에서 2번 째 칼럼은 1번 째 칼럼에 의존하여 정렬

복합 인덱스는 인덱스 내 각 칼럼의 위치(순서) 가 매우 중요하다.