책너두 6기 23일차
백은빈, 이성욱의 Real MySQL8.0 1권 p.237 ~ p.246
내용정리
08 인덱스
8.3.4.4 인덱스 스킵 스캔
-
데이터베이스 서버에서 인덱스의 핵심은 값이 정렬돼 있다는 것이며, 이로 인해 인덱스를 구성하는 칼럼의 순서가 매우 중요하다.
- 기존에 루스 인덱스 스캔이 비슷한 최적화를 수행했지만 새로 도입된 인덱스 스킵 스캔은 용도가 훨씬 넒어졌다.
- 단점
- Where 조건절에 조건이 없는 인덱스의 선행 칼럼의 유니크한 값의 개수가 적어야 함 : 개수가 많으면 인덱스에서 스캔해야 할 시작 지점을 검색하는 작업이 많이 필요해져 쿼리의 처리 성능이 오히려 더 느려질 수 있다.
- 쿼리가 인덱스에 존재하는 칼럼만으로 처리 가능해야 함(커버링 인덱스) : 이후 버전에서 개선될 것으로 보임
8.3.5 다중 칼럼(Multi-column)인덱스
- 현재 까지는 1개의 칼럼만 포함된 인덱스
- 두 개 이상의 칼럼으로 구성된 인덱스를 다중 칼럼 인덱스(복합 칼럼 인덱스)나 “Concatenated Index”라고 함
- 다중 칼럼 인덱스에서는 인덱스 내에서 각 칼럼의 위치(순서)가 상당히 중요하다.
8.3.6 B-Tree 인덱스의 정렬 및 스캔 방향
- 인덱스의 키 값은 항상 오름차순이거나 내림차순으로만 정렬되어 저장된다.
8.3.6.1 인덱스의 정렬
- 인덱스를 생성하는 시점에 인덱스를 구성하는 각 칼럼의 정렬을 오름차순 / 내림차순 으로 설정 가능
- 정렬 순서를 혼합할 수 있음.
8.3.6.1.1 인덱스 스캔 방향
- 인덱스 생성 시점에 오름차순 또는 내림차순으로 정렬이 결정되지만 쿼리가 그 인덱스를 사용하는 시점에 인덱스를 읽는 방향에 따라 오름차순 또는 내림차순 정렬 효과를 얻을 수 있다.
8.3.6.1.2 내림차순 인덱스
- 인덱스 역순 스캔이 인덱스 정순 스캔에 비해 느리다.
- 인덱스를 내림차순 정렬하는 쿼리가 소량의 레코드에 드물게 실행되는 경우라면 내림차순 인덱스를 굳이 고려할 필요는 없다.
- 많은 레코드를 조회하면서 빈번하게 실행된다면 내림차순 인덱스가 더 효율적일 수도 있다.
- 많은 쿼리가 인덱스의 앞쪽만 또는 뒤쪽만 집중적으로 읽어서 인덱스의 특정 페이지 잠금에서 병목이 예상된다면 쿼리에서 자주 사용되는 정렬 순서대로 인덱스를 생성하는 것이 잠금 병목 현상을 완화하는데 도움이 된다.
