커버링 인덱스(Covcering Index)
- 쿼리가 필요한 모든 컬럼의 값을 인덱스만 보고 조회할 수 있는 경우,
그 인덱스가 커버링 인덱스
- 즉, 테이블까지 접근할 필요 없이 인덱스에서만 모든 데이터를 가져올 수 있는 경우
- 쿼리를 수행할 때 인덱스만 보고도 결과를 낼 수 있는 상황
- ✨ 테이블 액세스 없이 처리된다는 점이 핵심
SELECT name, age FROM users WHERE email = 'abc@example.com';
CREATE INDEX idx_users_email_name_age ON users(email, name, age);
- 이 인덱스는 다음 순서로 데이터를 포함한다.
- 인덱스 구성요소인
email 은 위의 SQL 쿼리에서 검색 조건에 해당하고,
name과 age는 조회 컬럼에 해당하는데
SQL 쿼리가 요구하는 바(email로 필터링하고 name, age를 조회)와 상응하기에
인덱스만으로 쿼리 결과를 반환할 수 있어 커버링 인덱스에 해당된다.
- 즉,
email 을 검색 조건으로 사용하고, name과 age가
이미 인덱스 안에 포함돼있어, 인덱스만 보고 결과를 만들 수 있다 - 커버링 인덱스
커버링 인덱스의 성능상 이점
- 테이블 액세스를 생략(인덱스 레벨에서 처리 → 랜덤 I/O 감소)
- 디스크 I/O 절감
- 쿼리 속도 향상(🚀빠른 쿼리 수행)
커버링 인덱스 주의할 점
SELECT * 같은 쿼리는 효과 없음❗
(테이블 전체 컬럼을 참조하므로 인덱스로 커버 불가능하다)
- 인덱스에 너무 많은 컬럼을 포함시키면 쓰기 성능 저하 및 인덱스 크기 증가 우류
- 인덱스 컬럼 순서도 중요
(WHERE, SELECT 절을 모두 고려해 설계해야 함)
일반 인덱스 vs 커버링 인덱스 차이
| 구분 | 일반 인덱스 | 커버링 인덱스 |
|---|
| 인덱스 역할 | WHERE 조건 필터링에만 사용 | WHERE + SELECT 모든 컬럼을 포함 |
| 테이블 접근 | 추가 접근 필요
ROWID로 테이블에서 조회 컬럼을 가져옴 | 인덱스만으로 완료(테이블 접근❌) |
| 성능 | 느림(랜덤 I/O 발생) | 빠름(I/O 최소화) |
ref. https://jojoldu.tistory.com/476