다중 칼럼 인덱스

책너두 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 내림차순 인덱스 인덱스 역순 스캔이 인덱스 정순 스캔에 비해 느리다. 인덱스를 내림차순 정렬하는 쿼리가 소량의 레코드에 드물게 실행되는 경우라면 내림차순 인덱스를 굳이 고려할 필요는 없다. 많은 레코드를 조회하면서 빈번하게 실행된다면 내림차순 인덱스가 더 효율적일 수도 있다. 많은 쿼리가 인덱스의 앞쪽만 또는 뒤쪽만 집중적으로 읽어서 인덱스의 특정 페이지 잠금에서 병목이 예상된다면 쿼리에서 자주 사용되는 정렬 순서대로 인덱스를 생성하는 것이 잠금 병목 현상을 완화하는데 도움이 된다.