MySQL 실행계획을 보다 보면 type 값이 index로 표시되는 경우가 있다. 이는 인덱스를 사용하긴 하지만 조건 범위를 좁히지 못하고 인덱스의 처음부터 끝까지 모두 읽는 방식이다. 이를 인덱스 풀 스캔이라고 한다.
인덱스 레인지 스캔과 달리 선택도가 낮거나 조건절이 인덱스 선두 컬럼을 사용하지 못할 때 발생한다. 그럼에도 불구하고 테이블 풀 스캔보다 효율적인 경우가 존재한다.
인덱스 풀 스캔 개념과 특징
인덱스 풀 스캔은 인덱스를 사용하지만 조건에 의해 범위를 줄이지 못하고 리프 노드를 처음부터 끝까지 순차적으로 읽는다.
일반적으로 인덱스는 테이블 데이터보다 크기가 작다. 따라서 테이블 전체를 읽는 것보다 인덱스만 읽는 것이 디스크 I/O 측면에서 유리할 수 있다.
특히 커버링 인덱스로 처리되는 경우 테이블에 접근하지 않고 인덱스만으로 결과를 반환할 수 있다. 이 경우 랜덤 I/O가 발생하지 않고 리프 노드를 순차적으로 탐색하게 된다.
즉 인덱스 풀 스캔은 레인지 스캔보다는 효율이 떨어지지만 테이블 풀 스캔보다는 상황에 따라 더 나은 선택이 될 수 있다.
실행계획으로 보는 인덱스 풀 스캔
employees 테이블에 다음과 같은 복합 인덱스를 생성한다. 컬럼 순서는 매우 중요하다.
CREATE INDEX ix_full
ON employees(first_name, last_name, gender);
이 인덱스는 first_name → last_name → gender 순서를 지켜야 레인지 스캔이 가능하다.
하지만 조건절에서 last_name 또는 gender만 사용하는 경우 선두 컬럼을 사용하지 못하므로 인덱스 풀 스캔이 발생한다.
다음 쿼리는 인덱스 유무와 관계없이 테이블 풀 스캔으로 동작한다.
SELECT * FROM employees;
하지만 인덱스에 포함된 컬럼만 조회하면 인덱스를 사용할 수 있다.
SELECT first_name, last_name, gender
FROM employees;
인덱스가 없는 테이블에서는 type=ALL로 테이블 풀 스캔이 발생하지만 인덱스가 있는 경우 type=index로 인덱스 풀 스캔이 수행된다.
type=ALL은 테이블 풀 스캔, type=index는 인덱스 풀 스캔을 의미한다.
ORDER BY에서 인덱스 풀 스캔 효과
단순 조회에서는 테이블 풀 스캔과 인덱스 풀 스캔의 실행 시간이 크게 차이나지 않을 수 있다.
테이블 풀 스캔은 순차 I/O로 데이터를 읽고 인덱스는 랜덤 I/O가 발생하지만 커버링 인덱스라면 리프 노드를 순차적으로 읽게 된다.
차이는 정렬에서 명확하게 드러난다. ORDER BY 절을 사용하는 경우 테이블 풀 스캔은 추가적인 filesort가 필요하다.
반면 인덱스 풀 스캔은 이미 인덱스 자체가 정렬된 상태이므로 추가 정렬 작업이 발생하지 않는다.
SELECT first_name, last_name, gender
FROM employees
ORDER BY first_name, last_name;
테이블 풀 스캔에서는 Using filesort가 발생하고 실행 시간이 증가한다.
인덱스 풀 스캔에서는 Using index로 처리되며 정렬 비용 없이 빠르게 결과를 반환한다.
레코드 수가 많아질수록 이 차이는 더욱 크게 나타난다. 인덱스 크기가 테이블보다 작고 버퍼 풀에 캐싱될 확률도 높기 때문이다.
결론적으로 인덱스 풀 스캔은 조건 필터링보다는 정렬과 커버링 인덱스 활용에서 강점을 가진 실행 방식이다.