단일인덱스 & 복합인덱스

2. 단일 인덱스

2.1 단일 인덱스의 컬럼 정하기

• 특정테이블에 컬럼별 조건에따른 결과건수
  CUS_ID : 340,000
  PAY_TP : 9,150,000
  RNO : 3,047

• 인덱스 컬럼 선정 규칙중하나는 선택성이 좋은컬럼을 사용하는것.

• 데이터가적을수록 선택성이 좋음. 데이터가많을수록 선택성이 나쁘다.

• RNO컬럼을 인덱스로 생성하는게 효율은 가장좋다
  

  2.2 단일인덱스 VS 복합인덱스

• 복합인덱스는 2개이상의 컬럼으로 구성된 인덱스

• 복합인덱스는 단일인덱스를 능가하는 성능을 낼수있으며, 여러개의 인덱스를 대신할수도있다

• 인덱스가 조회속도개선에는 도움이되지만, 입력/수정/삭제에서는 성능이 감수한다.

• 1번필드를 인덱스로 구성하면 1번필드는 인덱스에서 찾을수있지만 2번필드는 테이블에 접근해야만 확인할수있다. 반면 복합인덱스로 1번필드 2번필드를 구성하면 모두 인덱스안에서 처리가능

• 인덱스에 없는 컬럼을 확인하기위해서는 테이블접근이 필수다, 적절한 컬럼수로 복합인덱스를 구성하여 성능향상을 고려해야한다.

3. 복합인덱스

3.1 복합인덱스 - 컬럼 선정과 순서

• 컬럼순서에 따라 완전히 다른 인덱스가되며 성능차이도 천차만별이다.
• 컬럼순서는 복합인덱스 구성의 가장 중요한 요소
• 쿼리성능 테스트에는 항상 버퍼캐시를 비우고 실행해본다.
• 복합인덱스 구성시 선택성이 좋은컬럼을 앞으로 구성하는것이 일반적으로 좋다.
• 등치조건 (=)을 사용하는 컬럼이 범위조건을 사용하는 컬럼보다 앞으로두는것이 일반적으로 좋다
• 절대적인 우선순위는 없으며 시스템 상황에맞게 적용하는것이 중요

3.2 복합인덱스 -컬럼 선정과 순서 2

• ORD_YMD 는 등치조건(=), CUS_ID는 범위조건
  =>ORD_YMD, CUS_ID순이좋음.
• ORD_YMD 는 범위조건, CUS_ID는 등치조건(=)
  =>CUS_ID, ORD_YMD순이 좋음

3.3 복합인덱스 - 컬럼 선정과 순서 3

• 자주사용하게될 비즈니스 로직을 고려한 설계가 필요.
• index range scan, index skip scan등 여러 스캔방식을 복합적으로 고려
• 한개의 인덱스로 여러 sql을 커버할수있도록 설계필요

3.4 복합인덱스 - 여러컬럼이 조건절에사용되는경우.

• 수많은 조회조건을 모두 인덱스로 구성하기는 어렵다.
• 조건별로 카운트를 해보고 적은건수의 데이터를 위주로 생성하는것이 유리
• 정리

  • 등치(=) 조건이 사용된 컬럼이 복합인덱스의 압부분에 위치
  • 인덱스생성시 해당테이블에 대한 SQL을 최대한 검토한다
  • 조건에 사용된 모든컬럼을 무조건 복합인덱스에 추가해서는안된다 (성능에 도움되는 조건컬럼만 선별)

4. 인덱스의 활용

4.1 인덱스로 커버된 SQL

• 데이터 검색시 테이블 접근(TABLE ACCESS BY INDEX ROWID)횟수를 줄이는것이 매우중요(랜덤액세스)
• 가져오는 컬럼의 수가 적을경우 테이블접근을 줄이기위해 하당컬럼을 인덱스에 추가하는 방법도 고려가 필요.

4.2 Predicate Information - Access

• 인덱스를 탔는지보다 제대로 탔는지가 중요.
• Predicate Information의 access, filter항목을 잘살펴보아야한다.

4.3 너무많은 인덱스의 위험성

• 인덱스가 너무많은경우, (테이블용량과 인덱스용량이 비슷해진다는등.) insert시의 부하가 매우 올라간다.
• 인덱스 생성전에는 충분한 고민이 필요하다는뜻(데이터 입력빈도, 조회빈도 등등)

4.4 인덱스 설계과정

• 1. SQL별 접근경로조사 : 개발된 모든 SQL확인, 조건, 형변환등확인 표로정리
• 2. 테이블별 접근 경로 정리 : 테이블별 조인조건 확인
• 3. 종합적인 인덱스 설계
• 4. 핵심 테이블 및 핵심 SQL 집중 설계
• 5. 인덱스 생성 및 모니터링 : 생성후에 모니터링을 통한 개선필요.