Covering Index(Using index)

실행계획 분석에 Extra 컬럼에 "Using index" 가 표시될 수 있다.
이 경우는 데이터 파일을 전혀 읽지 않고 인덱스만 읽어서 쿼리를 모두 처리할 수 있을 때 표시된다.

인덱스를 이용해 처리하는 쿼리에서 가장 큰 부하를 차지하는 부분은 인덱스 검색에서 일치하는 키 값들의 레코드를 읽기 위해 데이터 파일을 검색 하는 작업이다. 최악의 경우, 인덱스를 통해 검색된 결과 레코드 한 건 한 건마다 디스크를 한 번씩 읽어야 할 수도 있다.

// first_name 이 인덱스가 되어있는 경우
explain #1
select * from members where first_name between 'angel' and 'sunny';

explain #2
select first_name from members where first_name between 'angel' and 'sunny';

• #1 인 경우는 각 레코드의 컬럼의 값을 얻기 위해 각 레코드가 저장된 데이터 페이지를 조건절 만큼을 읽어야 한다. 이런 경우는 인덱스를 사용하는 것보다 풀 테이블 스캔으로 처리하는 편이 더 효율적으로 판단했기 때문이다.
  

• #2 이 쿼리에서는 members 테이블의 모든 컬럼으로 조회하지 않고 first_name 만 사용했다. 필요한 칼럼이 모두 인덱스에 있으므로 데이터 파일을 읽을 필요가 없다.
  => 인덱스만으로 처리되는 것을 커버링 인덱스 라고 한다.

InnoDb 일석이조

InnoDB 는 first_name 으로 인덱스로 설정해도 결국 인덱스에 PK 값이 저장된다. 아래와 같이 id 가 조회 필드에 추가돼도 Extra 필드는 Using index 로 나온다.

select first_name, id from members where first_name between 'angel' and 'sunny';

• InnoDB 의 세컨더리 인덱스에는 데이터 레코드를 찾기 위한 주소를 사용하기 위해 PK 를 저장하느느 것이지만, 추가 컬럼을 하나 더 가지는 인덱스의 효과를 동시에 얻을 수 있다.

type:index != Extra : Using index

• 쿼리 실행계획 분석에서 접근 방법(type)이 eq_ref, ref, range, index_merge, index 등과 같이 인덱스를 사용하는 실행 계획에서는 모두 Extra 컬럼에 "Using index" 가 표시 될 수 있다.
• 인덱스 풀 스캔(index) 와 혼동할 때가 자주 있지만, 성능상 반대되는 개념이라고도 할 수 있다.
  -> 같은 인덱스 풀 스캔이어도 커버링 인덱스인 경우가 훨씨 빠르게 처리된다.

참고

Real MySQL 8.0 1