인덱스 스캔 효율

덱스 참 잘생겼다. 덱스같은 아들 낳고싶다.

---

인덱스 스캔 효율 정리

(1) 인덱스 매칭도

• = , IN 조건이 아닌 조건 이후는 무조건 체크 조건
  • 드라이빙 조건을 만들어 줘야 한다.
  • 조회 조건이 = 이 아닌 컬럼은 가급적 인덱스 뒤쪽으로 배치
• 결합 인덱스 우선순위 결정
  • 자주(항상) 사용되는가?
  • = 조건
  • Cardinality (분포도)
  • 소트 연산 대체 가능 여부
• 인덱스 row 7 vs 결과 row 3 → 인덱스가 더 많을 경우 비효율 발생
  • 일부 컬럼에만 인덱스가 존재할 경우

---

(2) 비교 연산자 종류와 컬럼 순서에 따른 인덱스 레코드의 군집성 (인덱스 매칭도)

---

(3) 인덱스 선행 컬럼이 등치 (=) 조건이 아닐 때 발생하는 비효율 (인덱스 매칭도)

• Sequential 액세스 효율은 선택도에 의해 결정 → 얼마나 적은 레코드를 읽는가?
• 인덱스 컬럼이 조건절에 모두 = 조건일 때 가장 효율적
• 리프 블록을 스캔하면서 읽은 레코드는 모두 필터링 없이 테이블 액세스 → 비효율 0
• 인덱스 컬럼 중 일부가 조건절에서 생략되거나 = 조건이 아니어도 그것이 뒤쪽 컬럼이면 비효율이 없다.

---

(4) BETWEEN 조건을 IN-List로 바꿨을 때 인덱스 스캔 효율

주의사항

• IN-List 개수가 많지 않아야 한다.
• 수직적 탐색이 IN-List 횟수만큼 발생
• 수평적 스캔의 비효율보다 수직적 탐색의 비효율이 더 클 수 있음
• 인덱스 높이(height)가 높을 때 비효율 증가 가능

💡Tip: IN-List 가 많을 경우 Leaf Block의 비효율이 더 효율적일 수 있음

• 체크 조건 앞의 컬럼들이 변별력이 좋아 검색 구간을 줄였다면 BETWEEN 조건이 유리하다.

---

(5) Index Skip Scan을 이용한 비효율 해소

• 선두 컬럼이 BETWEEN & Distinct 갯수가 적을 때
• 수직적 탐색이 많은 IN-List 보다 Index Skip Scan 이 근소하게 유리

---

(6) 범위 조건을 남용할 때 발생하는 비효율

---

(7) 같은 컬럼에 두 개의 범위 검색 조건 사용 시 주의 사항

---

(8) BETWEEN 과 LIKE 스캔 범위 비교

• BETWEEN을 사용하는 것이 정확한 방식, LIKE는 개발자 편의에 의한 사용 방식
• BETWEEN을 사용했을 때 성능적으로 손해 보는 것은 없음
• Leaf Node에 존재하는 조건 검색 시 시작, 끝점을 찾는 경우는 = 같은 효과
  • LIKE → 일반적으로 Leaf Node에 없는 조건 검색

---

(9) 선분 이력의 인덱스 스캔 효율

• 선분 이력 → 데이터 변경 시작 시점(유효 시작 시점) ~ 변경 발생 시점(유효 종료 시점) 데이터 관리
• 최근 데이터를 주로 읽는다 → 인덱스 - 종료일자 + 시작일자
• 과거 데이터를 주로 읽는다 → 인덱스 - 시작일자 + 종료일자
• 인덱스 수정 불가 → Index_Desc 힌트 활용
• 중간지점 → 어떠한 인덱스든 비효율이 발생하나 ROWNUM ≤ 1 조건 활용 가능

---

(10) Access Predicate 와 Filter Predicate

---

(11) Index Fragmentation

인덱스 단편화(Index Fragmentation)는 데이터 삽입, 삭제, 갱신이 많아지면서 인덱스가 비효율적으로 관리되는 현상을 의미한다. 이를 해결하기 위해 Index Rebuild 또는 Index Coalesce 등을 활용할 수 있다.

---

마무리

인덱스 스캔의 효율을 높이기 위해서는 인덱스 설계부터 신중해야 하며,

실행 계획(Execution Plan) 분석을 통해 불필요한 범위 스캔을 줄이는 것이 중요함.

나는 그동안 LIKE를 참 많이 써왔는데,

오늘 배운바로는, Date 같은걸 like를 써서 확인하게 되면,

불필요한 partition까지 읽게 되는 경우가 생기더라. 주의해야 할것 같다.