3장 인덱스 튜닝 (2)

3장 인덱스 튜닝

3.3 인덱스 스캔 효율화

3.3.5 인덱스 선행 컬림이 등치(=) 조건이 아닐 때 생기는 비효율

• 인덱스 스캔 효율성은 인덱스 컬럼을 조건절에 모두 등치(=) 조건을 사용할 때 가장 좋다.

3.3.6 BETWEEN을 IN-List로 전환

• 선행 조건이 BETWEEN으로 비효율이 발생할 때 In-List로 바꿔주면 큰 효과를 얻을 수도 있다.
• 이때 주의 할 점은 IN-List 개수가 많지 않아야 한다.(수직적 탐색이 많아 질 수 있음)

3.3.7 Index Skip Scan 활용

• BETWEEN을 IN-List로 변환하는 것 대신 Index Skip Scan을 활용하는 방법도 있다.

3.3.8 IN 조건은 '=' 인가

• IN 조건은 '='이 아니다.

3.3.9 BETWEEN과 LIKE 스캔 범위 비교

• LIKE보다 BETWEEN이 낫다.

3.3.10 범위검색 조건을 남용할 때 생기는 비효율

• 코딩을 쉽게 하려고 인덱스 컬럼에 범위검색 조건을 남용하지 말라.

3.3.11 다양한 옵션 조건 처리 방식의 장단점 비교

• 인덱스 선두 컬럼에 대한 옵션 조건에 OR 조건을 사용하지 말라
• 변별력이 좋은 필수 조건이 있는 상황에서는 LIKE/BETWEEN 사용 가능
• UNION ALL 방식은 옵션 조건 컬럼도 인덱스 액세스 조건으로 사용한다
• NVL/DECODE 사용하면 UNION ALL 보다 단순하면서도 비슷한 성능을 낼 수 있다.

3.3.12 함수호출부하 해소를 위한 인덱스 구성

• PL/SQL은 매우 느리다.
• 특히 안에서 SQL을 실행하면 Recursive call이 일어나기 때문에 매우 비효율적이다.

3.4 인덱스 설계

3.4.1 인덱스 설계가 어려운 이유

• 인덱스가 많으면 생기는 문제
  • DML 성능 저하
  • 데이터베이스 사이즈 증가
  • 테이터베이스 관리 및 운영 비용 상승

3.4.2 가장 중요한 두 가지 선택 기준

• 인덱스 선택 기준
  • 조건절에 항상 사용하거나, 자주 사용하는 컬럼을 선정하다.
  • '=' 조건으로 자주 조회하는 컬럼을 앞에 둔다.

3.4.3 스캔 효율성 이외의 판단 기준

• 수행 빈도
• 업무상 중요도
• 클러스터링 팩터
• 데이터량
• DML 부하
• 저장 공간
• 인덱스 관리 비용

3.4.4 공식을 초월한 전략적 설계

모든 조건절을 고려하여 인덱스를 다 만들수는 없다. 도메인에 맞게 전략을 구성하여 최적 인덱스를 구성한다.

3.4.5 소트 연산을 생략하기 위한 컬럼 추가

조건절에 사용하지 않는 컬럼이더라도 소트 연산을 생략할 목적으로 인덱스 구성에 포함시켜서 성능 개선 도모

3.4.6 결합 인덱스 선택도

인덱스 생성 여부를 결정할 때는 선택도가 충분히 낮은지가 중요한 판단기준이다.

3.4.7 중복 인덱스 제거

중복되는 인덱스는 제거한다. 중복으로 보이지 않는다 하더라도 평균 카디널리티가 낮다면 사실상 중복으로 본다.

3.4.8 인덱스 설계도 작성

인덱스 설계에도 전체를 조망할 수 있는 설계도면이 필요한다.