Covering Index (커버링 인덱스)

1️⃣ Covering Index란?

쿼리에 필요한 모든 컬럼이
인덱스 안에 이미 들어 있어서
테이블을 아예 읽지 않아도 되는 상태

즉,

• 인덱스 탐색 ✔
• 테이블(Row) 접근 ❌

---

2️⃣ 왜 테이블 접근이 그렇게 비싼가?

InnoDB 기준으로 보면:

• 인덱스(B+Tree) → PK 값만 있음
• 실제 데이터는 → Clustered Index(테이블) 에 있음

그래서 보통 쿼리는:

인덱스 탐색
 → PK 추출
 → 테이블에서 PK로 다시 조회 (Random I/O)

Covering Index는 두번째 단계를 완전히 제거한다.

 

---

3️⃣ 예제

❌ 일반 인덱스

-- 인덱스
(COMPCD, PLCBUS, YEARXX, DOCSEQ)

-- 쿼리
SELECT *
FROM HERGMT
WHERE COMPCD = ?
  AND PLCBUS = ?
  AND YEARXX = ?
ORDER BY DOCSEQ DESC
LIMIT 30;

동작:

1. 인덱스로 DOCSEQ 30개 찾음
2. 각 row마다 테이블 접근 (30번)

---

✅ Covering Index

-- 인덱스
(COMPCD, PLCBUS, YEARXX, DOCSEQ, DOCSTAT, REGDT)

-- 쿼리
SELECT DOCSEQ, DOCSTAT, REGDT
FROM HERGMT
WHERE COMPCD = ?
  AND PLCBUS = ?
  AND YEARXX = ?
ORDER BY DOCSEQ DESC
LIMIT 30;

동작:

1. 인덱스로 조건 + 정렬 처리
2. 필요한 컬럼이 전부 인덱스에 있음
3. 테이블 접근 0회

👉 성능 체감이 확 달라짐

---

4️⃣ 결론1

Covering Index는
“DB가 테이블을 열어보지 않아도
답을 알 수 있게 만드는 설계”다.

---

5️⃣ 나의 질문

실무에서 대부분 쿼리는 10개 이상의 컬럼이 필요한데, 서브쿼리나 Join 사용할때 사용하는게 맞나?

결론부터 말하면 👇

✅ 맞다. 컬럼이 10개 이상 필요한 경우엔
Covering Index는 “최종 조회”가 아니라
👉 서브쿼리 / 2단계 조회에서 가장 빛난다.

즉,
“결과를 다 뽑는 쿼리”보다
“대상을 빠르게 추리는 쿼리”에 쓰는 게 정석.

 

---

6️⃣ 왜 컬럼이 많으면 Covering Index가 애매해질까?

Covering Index의 전제

쿼리에 필요한 컬럼이 전부 인덱스에 있다

근데 실무에서:

• 목록 화면만 해도 10~15개 컬럼
• JOIN까지 들어가면 더 늘어남

이걸 전부 인덱스에 넣으면:

• 인덱스 폭발
• 쓰기 성능 급락
• 메모리 압박

👉 그래서 “전체 SELECT”를 커버하려는 시도는 보통 실패

---

7️⃣ 실제 사용법

서브쿼리, EXIST, JOIN 등과 궁합이 좋음

-- 🔥 EXISTS 패턴 (강추)

SELECT *
FROM MAIN M
WHERE EXISTS (
    SELECT 1
    FROM HERGMT H
    WHERE H.COMPCD = M.COMPCD
      AND H.DOCSEQ = M.DOCSEQ
      AND H.STATUS = '10'
);

인덱스: (COMPCD, DOCSEQ, STATUS)


-- JOIN에서도 “앞단 필터”로 매우 좋다

SELECT *
FROM HERGMT H
JOIN (
    SELECT DOCSEQ
    FROM HERGMT
    WHERE COMPCD = ?
      AND PLCBUS = ?
      AND YEARXX = ?
    ORDER BY DOCSEQ DESC
    LIMIT 30
) T
ON H.DOCSEQ = T.DOCSEQ;

인덱스: (COMPCD, PLCBUS, YEARXX, DOCSEQ)

특히 EXISTS와 궁합이 좋으며, EXISTS 사용시 조건에 맞는 순간 즉시 TRUE를 반환한다.
그동안 습관적으로 IN을 사용해왔는데, 값 목록이 아닌 존재 여부만 묻는 EXISTS를 더 중용하도록 하자

---

8️⃣ 정리하면, Covering Index는 “역할”이 있다

❌ 이런 용도는 부적합

• SELECT * 목록 전체 커버
• 컬럼 수 10~20개 한 번에 다 뽑기

✅ 이런 용도로 최적

• ID / PK / 상태 / 날짜만 필요한 쿼리
• EXISTS / IN / JOIN의 앞단
• 페이징 대상 추출
• 서브쿼리에서 “대상 좁히기”

---

9️⃣ 결론2

Covering Index는
“결과를 만드는 기술”이 아니라
“대상을 빠르게 줄이는 기술”이다.