인덱스 튜닝 (1)

SQL 튜닝은 랜덤 I/O 와의 싸움이라고 봐도 무방하다.

• DBMS가 제공하는 많은 기능, 조인 메서드의 발전은 물론 많은 튜닝 기법도 랜덤 I/O의 최소화에 맞춰져 있다.

테이블 랜덤 엑세스

" 인덱스 만으로 충분한데, 관리적 측면을 제외하고 성능적 측면에서 파티션이 필요할까요?"

라는 질문을 시작으로 테이블 랜덤 엑세스가 성능에 미치는 영향을 알아 보자.

• 대량 데이터를 조회 할 때, 인덱스를 사용하면 테이블 전체를 스캔하는 것 보다 느리다.

인덱스로 스캔하는데 왜 느릴까?

select * from 고객 where 지역 = '서울';

Execution Plan
-----------------------------------
0   SELECT STATEMENT Optimizer=ALL_ROWS
1 0   TABLE ACCESS BY INDEX ROWID OF '고객' (TABLE)  <-인덱스를 스캔한 후에 테이블을 반드시 스캔!
2 1     INDEX RANGE SCAN OF '고객_지역_IDX' (INDEX) 

• 인덱스를 스캔하는 이유는? ROWID (논리적 주소)를 얻기 위해.
• ROW ID = 데이터 정보가 있는 물리적 주소가 아닌 디스크 상에서 테이블 레코드를 찾아가기 위한 정보를 담고 있다.

"오라클은 테이블 블록이 수시로 버퍼캐시에 밀려 났다가 다시 캐싱되며, 그때마다 따른 공간에 캐싱되기 때문에 인덱스에서 포인터로 직접 연결할 수 없는 구조로 이루어져 있다. 메모리 주소 정보가 아닌 디스크 주소 정보를 이용해 해시 알고리즘으로 버퍼 블록을 찾아간다."

결론: 일반 DBMS 에서 인덱스 ROWID를 이용한 테이블 엑세스가 생각만큼 빠르지 않다.
그렇기 때문에 파티션 Pruning 을 사용한다.

인덱스 클러스터링 팩터

클러스터링 팩터란?

• 특정 컬럼을 기준으로 같은 값을 갖는 데이터가 서로 모여있는 정도.
• 클러스터링 팩터가 좋은 컬럼에 생성한 인덱스는 검색 효율이 좋다.
  (테이블 엑세스양에 비해 블록 I/O가 적게 발생함을 의미한다.)
  

클러스터링 팩터가 가장 종은 예

• 인덱스 클러스터링 팩터 효과
  - ROWID로 테이블을 엑세스 할때, 오라클은 래치획득과 해시체인스캔과정을 거쳐 오렵게 찾아간 테이블 블록에 대한 포인터를 바로 해제하지 않고 일단 유지한다.-> 버퍼피닝(Buffer Pinning)

  • 이 상태에서 마침 '직전과 같은' 테이블 블록을 가리킨다면, 래치 획득과 해시체인스캔과정을 생략하고 바로 테이블 블록을 읽을 수있다.(논리적 블록 I/O 과정 생략가능)

    

  • 굵은 실선을 실제 블록 I/O 가 발생하는 경우
  • 가는 점선은 블록을 찾아가는 과정없이 포인터로 바로 엑세스 하는 경우이다.(버퍼피닝 효과 극대화,클러스터링 팩터의 중요성)
  • 그림과 같이 인덱스 레코드와 테이블 레코드의 정렬순서가 100% 일치 할 필요는 없다.
    다음의 읽을 테이블 블록과 직전에 읽은 테이블 블록의 주소가 같기만 하면 된다.