TIL
  • Contents
  • Book
    • 도메인 주도 설계
      • 1. 동작하는 도메인 모델 만들기
    • 오브젝트
      • 데이터 중심 설계
      • 책임 중심 설계
      • 책임 할당을 위한 GRASP 패턴
      • 메시지와 인터페이스
      • 객체 분해
    • Effective Java
      • Item 7 - 다 쓴 객체 참조를 해제하라
      • Item 7 발표 내용
      • Item 13 - clone 재정의는 주의해서 진행하라
      • Item 13 발표 내용
      • Item 16 - public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
      • Item 16 발표 내용
      • Item 26 - 로 타입은 사용하지 말라
      • Item 28 - 배열보다는 리스트를 사용하라
      • Item 28 발표 내용
      • Item 29 - 이왕이면 제네릭 타입으로 만들라
      • Item 30 - 이왕이면 제네릭 메서드로 만들라
      • Item 31 - 한정적 와일드 카드를 사용해 API 유연성을 높이라
      • Item 35 - ordinal 메서드 대신 인스턴스 필드를 사용하라
      • Item 37 - ordinal 인덱싱 대신 EnumMap을 사용하라
      • Item 37 발표 내용
      • Item 43 - 람다보다는 메서드 참조를 사용하라
      • Item 43 발표 정리
      • Item 56 - 공개된 API 요소에는 항상 문서화 주석을 작성하라
      • Item 56 발표 정리
      • Item 62 - 다른 타입이 적절하다면 문자열 사용을 피하라
      • Item 62 발표 정리
      • Item 73 - 추상화 수준에 맞는 예외를 던지라
      • Item 83 - 지연 초기화는 신중히 사용하라
      • Item 83 발표 내용
      • Item 89 - 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라
      • Item 89 발표 내용
    • 개발자를 위한 SQL 튜닝
      • SQL 쿼리 실습을 위한 DB 서버 구축
      • 인덱스 튜닝
      • 인덱스 스캔 튜닝
      • 인덱스 스캔 튜닝 실습
      • 인덱스 패스트 풀 스캔
      • 테이블 풀 스캔 튜닝
      • 조인 튜닝
      • 중첩 루프 조인 튜닝
      • 중첩 루프 조인 튜닝 실습
      • 해시 조인 튜닝
      • 해시 조인 튜닝 실습
      • 세미 조인 튜닝
      • 세미 조인 튜닝 실습
      • 아우터 조인
      • 함수 튜닝
      • 부분 범위 처리 튜닝
      • 파티셔닝 튜닝
      • 파티션 인덱스 튜닝
      • 병렬 처리 튜닝
  • Java
    • Design Pattern
      • Intro
      • Types of Design Patterns
      • Creational
        • Builder Pattern
        • Singleton Pattern
        • Prototype Pattern
        • Factory Pattern
        • Abstract Factory Pattern
      • Structural
        • Adapter Pattern
        • Bridge Pattern
        • Composite Pattern
        • Decorator Pattern
        • Facade Pattern
        • Flyweight Pattern
        • Proxy Pattern
      • Behavioural
        • Chain of Responsibility Pattern
        • Command Pattern
        • Interpreter Pattern
        • Iterator Pattern
        • Mediator Pattern
        • Memento Pattern
        • Observer Pattern
        • State Pattern
        • Strategy Pattern
        • Template Method Pattern
        • Visitor Pattern
    • Java
      • Cracking the Coding Interview
      • TDD, Clean Code with Java 11기
        • 자동차 레이싱
        • 로또
        • 사다리 타기
        • 볼링 게임 점수판
    • 궁금증
      • 자바 8 버전의 인터페이스와 추상클래스
      • 자바의 제네릭은 어떻게 이전 버전과 호환되는 걸까?
      • 스프링 MVC 기본 구조
      • 마샬링과 직렬화
      • 인터뷰 질문 모음
      • Code Coverage
  • Database
    • Database
      • SQL 레벨업
      • DB 스터디
        • DBMS
          • MySQL
        • INDEX
        • Join(Nested Loop, Hash)
        • Join(Semi, Outer)
        • Partial Range Processing
        • Function
        • Partitioning
        • Parallel Processing
  • Network
  • Architecture
    • Issue
      • Git Push Error
      • SonarLint Warning - assertThatExceptionOfType()
  • Infra
  • Spring
    • Spring JPA
      • 1. 데이터 모델링 및 연관관계 설정
      • 2. 최적화 내용
      • 3. Spring-Data-Jpa
      • 4. Query DSL
    • Spring Security
      • Intro
    • Spring Batch
      • 배치용 디비 설치
      • 배치 데이터 분석하기
      • 배치 프로세스 구상하기 및 성능 차이 확인하기
  • Issue
  • Tistory
    • Tistory Blog
  • Design High Performing Architectures
  • Design Resilient Architectures
  • Design Secure Applications And Architectures
  • Design Cost-Optimized Architectures
Powered by GitBook
On this page
  • 선택도
  • 인덱스 손익 분기점
  • 테이블 풀 스캔 튜닝
  • 실습
  • 테이블 풀 스캔을 유도하여 비효율적인 인덱스 스캔 예방하기
  • 튜닝 전 상황
  • 튜닝 후 상황

Was this helpful?

  1. Book
  2. 개발자를 위한 SQL 튜닝

테이블 풀 스캔 튜닝

인덱스 스캔

Previous인덱스 패스트 풀 스캔Next조인 튜닝

Last updated 3 years ago

Was this helpful?

내용에서 참고한 내용입니다.

선택도

  • 인덱스 스캔이 테이블 풀 스캔에 비해 반드시 유리하진 않는다.

  • 선택도가 낮은 컬럼(SEX)을 인덱스로 생성하여 인덱스 스캔을 수행하는 경우, 테이블 전체 행들의 50%에서 인덱스 스캔을 통한 테이블 랜덤 액세스가 발생하게 된다.

  • 일반적인 인덱스 스캔은 싱글 블록 I/O 읽기 인데, 테이블 풀 스캔은 멀티 블록 I/O 읽기이다.

  • 두 가지 이유로 SEX라는 컬럼을 조건절에 조건을 주어 스캔할 경우 인덱스 스캔보다 테이블 풀 스캔이 더 유리하다.

선택도(Selectivity) 구하는 공식

선택도(%) = ( 1 / Distinct Value ) * 100

인덱스 손익 분기점

  • 인덱스 손익 분기점은 인덱스 스캔보다 테이블 풀 스캔이 유리한 선택도의 수치를 의미한다.

    • 일반적으로 선택도가 15%보다 크다면 테이블 풀 스캔이 유리하고, 그 이하라면 인덱스 스캔이 더 유리하다.

테이블 풀 스캔 튜닝

  • 테이블 풀 스캔 튜닝은 선택도가 높은 컬럼의 인덱스를 사용하여 인덱스 스캔을 하는 SQL문을 강제로 테이블 풀 스캔으로 처리하도록 하는 기법

  • 즉, 손익 분기점을 넘어 인덱스 스캔하기에는 비효율적인 SQL을 강제로 테이블 풀 스캔을 하도록 처리하는 것이다.

실습

테이블 풀 스캔을 유도하여 비효율적인 인덱스 스캔 예방하기

  • 테이블 생성

CREATE TABLE TB_ORD
(
    ORD_NO VARCHAR2 (10), -
    -
    주문번호
    ORD_DT
    VARCHAR2
(
    8
), --주문일자
    ORD_NM VARCHAR2(150), --주문이름
    ORD_AMT NUMBER(15), --주문금액
    PRDT_CD VARCHAR2(6), --상품코드
    SALE_GB VARCHAR2(2), --판매구분
    PAY_GB VARCHAR2(2), --결제구분
    CUST_ID VARCHAR2(10), --고객ID
    INST_DTM DATE, --입력시간
    INST_ID VARCHAR2(50), --입력자ID
    UPDT_DTM DATE, --수정시간
    UPDT_ID VARCHAR2(5) --수정자ID
);
  • 데이터 입력

CREATE TABLE DUAL_1000
(
    DUMMY CHAR(1)
);

INSERT INTO DUAL_1000
SELECT DUMMY
FROM DUAL CONNECT BY LEVEL <= 1000;

COMMIT;

ALTER TABLE TB_ORD NOLOGGING;

INSERT /*+ APPEND */ INTO TB_ORD -- APPEND 힌트 사용
SELECT LPAD(TO_CHAR(ROWNUM), 10, '0'),
       TO_CHAR(SYSDATE - TRUNC(DBMS_RANDOM.VALUE(1, 3650)), 'YYYYMMDD'),
       DBMS_RANDOM.STRING('U', 150),
       TRUNC(DBMS_RANDOM.VALUE(1000, 100000)),
       LPAD(TO_CHAR(MOD(TRUNC(DBMS_RANDOM.VALUE(1, 1000)), 50)), 6, '0'),
       LPAD(TO_CHAR(MOD(TRUNC(DBMS_RANDOM.VALUE(1, 1000)), 3)), 2, '0'), -- SALE_GB
       LPAD(TO_CHAR(MOD(TRUNC(DBMS_RANDOM.VALUE(1, 1000)), 10)), 2, '0'),
       LPAD(TO_CHAR(TRUNC(DBMS_RANDOM.VALUE(1, 100000))), 10, '0'),
       SYSDATE,
       'DBMSEXPERT',
       NULL,
       NULL
FROM DUAL_1000,
     (SELECT LEVEL LV FROM DUAL CONNECT BY LEVEL <= 10000);

COMMIT;
  • 기본키 생성

ALTER TABLE TB_ORD
    ADD CONSTRAINT TB_ORD_PK
        PRIMARY KEY (ORD_NO);
  • 선택도 확인

SELECT ROUND(1 / COUNT(DISTINCT SALE_GB) * 100, 2) 선택도
FROM TB_ORD;
  • 인덱스 생성

CREATE INDEX TB_ORD_IDX01 ON TB_ORD (SALE_GB);
  • 통계정보 생성

ANALYZE TABLE TB_ORD COMPUTE STATISTICS
    FOR TABLE FOR ALL INDEXES FOR ALL INDEXED COLUMNS SIZE 254;

튜닝 전 상황

  • 튜닝 전 SQL

SELECT /*+ INDEX(TB_ORD TB_ORD_IDX01) */
    *
FROM TB_ORD
WHERE SALE_GB IN ('01', '02');
  • SQL 분석

    • INDEX 힌트를 사용하여 TB_ORD_IDX01 인덱스 스캔을 하도록 유도한다.

  • SQL 문제점

    • SALE_GB 컬럼은 33.3%로 선택도가 높은 컬럼임에도 인덱스 스캔을 하였다.

    • 테이블 풀 스캔은 테이블 랜덤 액세스를 하지 않으므로 이런 경우에는 오히려 테이블 풀 스캔이 더 성능이 좋다.

    • 인덱스 스캔 시 싱글 블록 I/O 읽기를 하게 되면 테이블 랜덤 액세스를 하므로 성능 부하가 있는 SQL문이 된다.

    • 이런 경우 인덱스 스캔을 한다고 하더라도 반드시 효율적으로 SQL문이라고 볼 수 없다.

  • Execute Plan

    • TB_ORD 테이블을 인덱스 범위 스캔(INDEX RANGE SCAN) 한다.

    • TB_ORD_IDX01 인덱스 스캔 후 나온 ROWID를 이용하여 테이블 랜덤 액세스(TABLE ACCESS BY INDEX ROWID)를 수행한다.

    • IN 조건 안에 있는 SALE_GB 컬럼의 값을 기준으로 ID 3번과 2번을 반복하게 된다.

    • IN 조건을 사용할 경우 오라클은 내부적으로 IN절 안에 있는 값을 기준으로 반복해서 비교하게 된다.

    • 즉, 처음에는 SALE_GB = '01'로 비교하고 다음에는 SALE_GB = '02'로 비교하게 된다.

    • '=' 연산으로 N번 비교하는 것이 특징, 이런 연산을 인 리스트 반복자(INLIST ITERATOR)라고 한다.

튜닝 후 상황

  • 튜닝 후 SQL

SELECT /*+ FULL(TB_ORD) */
    *
FROM TB_ORD
WHERE SALE_GB IN ('01', '02');
  • SQL 분석

    • TB_ORD 테이블을 풀 스캔하기 위해서 FULL 힌트사용

    • 테이블 전체를 멀티 블록 I/O 읽기 방식으로 읽었으며, 테이블 랜덤 액세스도 발생하지 않아 TB_ORD_IDX01 인덱스를 사용한 인덱스 스캔보다 성능이 빨라졌다.

  • Execute Plan

    • TB_ORD 테이블을 테이블 풀 스캔(TABLE ACCESS FULL)한다.

    • SELECT 절의 연산을 수행한다.

개발자를 위한 오라클 SQL 튜닝