[Real MySQL 8.0] 10.3 실행 계획 분석

10.3.5 type 컬럼

MySQL 서버가 각 테이블의 레코드를 어떻게 읽었는지 알 수 있다.

ALL: 풀 스캔 -> 가장 성능이 안좋음

index_merge 를 제외하고 모두 하나의 인덱스를 탄다.

12가지 타입이 있다.

[1] system

InnoDB에는 없다. 레코드 0, 1 인 테이블을 읽는 방식

[2] const

테이블 레코드 수, 조인 순서와 관계없이 유니크 키(PK) 컬럼을 이용해서 동등 비교로 조회할 때 사용하는 방식. 한 건의 레코드를 반환해서 const 라고 한다.

[3] eq_ref

여러 테이블의 조인에서 표시되는 타입.

조인에서 두 번째 이후에 읽는 테이블에서 반드시 1건만 조회된다는 보장이 있을 때 사용 가능한 방식.

첫번째 읽은 컬럼 값이 두번째 테이블의 유니크 키 또는 PK가 된다.

[4] ref

동등 조건으로 조인된 쿼리에서 나타나는 방식.

eq_ref와 다르게 조인 순서가 상관 없다. 그만큼 eq_ref보다 느리지만 그래도 동등조건만으로 비교되므로 빠르다.

[5] fulltext

Full-text Search 인덱스를 사용해 레코드를 읽는 접근 방법.

사용하기 위해서는 Full-text Search 인덱스가 이미 정의된 상태이어야한다. 

[6] ref_or_null

ref + IS NULL

[7] unique_subquery

WHERE 절의 IN (SUBQUERY)형태의 쿼리에 사용.

서브쿼리에 중복되지 않는 유니크한 값만 반환될 때 사용되는 접근 방법.

[8] index_subquery

IN (...) 에 오는 안쪽 파라메터는 중복된 값을 필터링할 필요가 있다. 파라메터로 서브쿼리가 사용되고, 인덱스를 이용해서 중복된 결과를 제거할 수 있을 때 사용되는 방식. 중복을 처리한다는 점에서 unique_subquery와 다르다.

[9] range

인덱스 레인지 스캔 형태의 접근 방식. 인덱스를 사용해서 범위 검색. 우선순위는 낮지만 상당히 빠른 방식.

[10] index_merge

2개 이상의 인덱스로 각각의 결과를 내고, 서로 합치는 접근 방식

[11] index

인덱스 풀 스캔. 효율적으로 필요한 부분만 읽는 방식이 아니다.

[12] ALL

풀 스캔.

 

10.3.6 possible_keys 컬럼

최적의 실행 계획을 만들기 위해 사용될 뻔한 키들의 목록. 별로 볼 필요 없다.

 

10.3.7 key 컬럼

최종 선택된 실행 계획에서 사용되는 인덱스의 목록. 쿼리 튜닝 시 여기 목록의 인덱스를 확인해서 의도 했던 인덱스가 표시되는지 체크한다.

실행 계획 타입이 ALL인 경우, 인덱스를 활용하지 못하므로 key 컬럼은 NULL.