[SQL] 실행 계획

• 최적 실행 경로의 처리 절차
• 읽기
  • 출력된 실행 계획에서 위쪽에 출력된 결과일수록 먼저 접근한 테이블
  • 접근한 순서는 ID 컬럼으로 확인할 수 있음, SELECT 절 하나당 다른 ID가 부여됨
  • ID, SELECT_TYPE, ROWS, EXTRA 컬럼 위주로 분석
• SELECT_TYPE : 어떤 타입의 쿼리인지 표시되는 컬럼
  • SIMPLE
    • 단순 SELECT 쿼리
  • PRIMARY
    • UNION이나 SUBQUERY를 포함하는 가장 바깥쪽에 있는 단위 쿼리
  • SUBQUERY
    • FROM절 이외에서 사용되는 SUB QUERY
  • UNION
    • 합집합이 되는 대상 쿼리
  • DEPENDENT(SUBQUERY | UNION) - 느림
    • 각 항목과 동일하지만 UNION이나 SUBQUERY가 바깥쪽의 쿼리의 값을 참조해서 사용하는 쿼리
  • DRIVED - 느림
    • SUBQUERY가 FROM절에서 사용되는 경우, 실행결과를 메모리나 디스크에 임시 테이블로서 생성하는 것을 의미함 (index 사용할 수 없음)
  • UNCACHEABLE SUBQUERY - 느림
    • SUBQUERY를 수행하는데 캐시를 사용하지 못하는 경우
• TYPE: 각 테이블의 레코드를 어떤 방식으로 읽었는지를 의미
  • system
    • 레코드가 1건만 존재하거나 없는 테이블, InnoDB에서는 볼일 없음
  • const
    • PK나 Unique 컬럼을 이용하는 Where 조건절로 1건을 반환하는 경우 (유니크 인덱스 스캔)
  • eq_ref
    • 조인에서 첫번째 읽은 테이블의 컬럼 값을 이용해 두번째 테이블의 PK나 Unique로 동등조건 검색하는 경우
  • ref / ref_or_null
    • 조인의 순서와 인덱스의 종류에 관계없이 동등 조건으로 검색하는 경우(1건 아니어도 됨) / ref랑 같은데 NULL도 포함되는 경우
  • uniq_subquery
    • IN 절 안의 서브쿼리에서 PK나 Unique가 오는 경우
  • range
    • 특정 범위 내에서 인덱스를 사용하여 데이터를 조회하는 경우
    • 인덱스에서 데이터 확인 후 실제 Record에 접근하여 데이터를 한번 더 가져와야 함
  • index - 느림
    • 모든 index를 스캔하는 경우, index라는 이름으로 착각하지 말 것, 하지만 limit 절과 함께라면 괜찮음
  • all - 느림
    • 풀 테이블 스캔하는 경우, 지양할 것
• ROWS
  • 조건을 만족하는 레코드를 찾기 위해 몇 개의 레코드를 검사해야하는지 확인하는 컬럼
  • 일반적인 경우라면 옵티마이저가 순서를 조정해주긴 하지만 JOIN의 테이블 접근 횟수 생각해 볼 것
• EXTRA: 이름은 EXTRA지만 중요한 부가정보를 포함하고 있음
  • Using Index / Using Index for group by
    • 인덱스만을 사용하여 데이터 처리 가능, 좋은 성능을 보장함
  • Distinct / Not exist
    • 조건에 해당하는 레코드를 찾았을 때 다른 레코드의 조합이나 있는지를 검사하지 않음, 좋은 성능을 보장함
  • Using temporary
    • 중간 처리 결과를 담아두기 위해 임시 테이블을 사용함
    • 임시 테이블은 파생 테이블(Derived Table)이라고 하기도 하는데 성능에 대한 고민이 필요함
  • Using filesort
    • 인덱스를 사용하지 못한 정렬을 수행할 때 메모리 버퍼에 정렬용 데이터를 복사해서 정렬함
    • 3번과 같이 나오는 경우가 많음
    • 부하를 일으킬 가능성 높음
  • Using Where
    • 검색 결과에 대한 레코드를 가공 또는 연산하는 작업을 수행하는 경우