|
Explain 정보보는법
인덱스가 적절히 사용되고 있는지 검토
나열된 순서는 MYSQL 이 쿼리처리에 사용하는 순서대로 출력
EXPLAIN 의 각 행 설명
A.
id :
쿼리 처리 순서
B.
select_type:
SELECT
의 타입
(
종류)
- SIMPLE:
단순 SELECT (UNION 이나 SUB-QUERY가 없는 SELECT 문)
- PRIMARY:
SUB-QUERY를 사용할 경우 SUB-QUERY 의 외부에 있는 쿼리(첫번째 쿼리)
UNION 을 사용할 경우 UNION의 첫번째 SELECT 쿼리.
- UNION:
UNION 쿼리에서 PRIMARY를 제외한 나머지 SELECT
- DEPENDENT UNION:
UNION 과 동일하나, 외부쿼리에 의존적임 (값을 공급 받음)
- UNION RESULT
UNION 쿼리의 결과물
- SUBQUERY:
SUB-QUERY
또는 SUB-QUERY를 구성하는 여러 쿼리 중 첫번째 SELECT문
- DEPENDENT SUBQUERY:
SUB-QUERY
와 동일하나
, 외곽쿼리에 의존적임
(
값을 공급 받음)
- DERIVED:
SELECT 로 추출된 테이블 (FROM 절 에서의 서브쿼리 또는 INLINE VIEW)
- UNCACHEABLE SUBQUERY:
SUB-QUERY와 동일하지만, 공급되는 모든 값에 대해 SUB-QUERY를 재처리. 외부쿼리에서 공급되는 값이 동일하더라도 CACHE된 결과를 사용할수 없음.
- UNCACHEABLE UNION:
UNION
과 동일하지만, 공급되는 모든 값에 대하여 UNION 쿼리를 재처리.
C.
table:
table
명 혹은 Alias
D.
type:
data access
타입, 우수한 순서대로... 뒤로갈수록 나쁜 조인형태
-
system
테이블에 오직 하나의 row만 있어 테이블에매칭되는 row가 무조건 1건인 경우, Const 타입의 특별한 케이스
- const
매칭되는 row가 오직 1건인 경우
가장 빠른 경우이며, 옵티마이저가 row을 찾기 위해 Unique/Primary Key 사용
각 컬럼 값은 나머지 연산에서 상수로 간주, 처음한번만 읽어 들이면 되므로 매우 빠름
- eq_ref
이전 테이블에서 공급받은 값으로 조인 처리시 단 하나의row만이 조인되는 테이블에 존재하는 경우
조인 타입 중 거의 최상의 경우이며, 조인되는테이블의 Unique/Primary Key를 사용 (1:1 관계)
- ref
이전 테이블에서 공급받은 값으로 조인 처리시 하나 이상의row가 조인되는 테이블에 존재하는 경우
조인을 처리할 때 Unique/Primary Key를 100% 사용하지 못하거나 Non-Unique 인덱스를 사용 (1:n 관계)
단일 쿼리인 경우 WHERE 조건 처리를 위해 Non-Unique 인덱스를 사용
인덱스를 사용하지만 제공되는 값에 매칭되는 row가많지 않은 경우 나쁘지 않은 타입임
- ref_or_null
ref 와 같지만 IS NULL 최적화가 수행 됨
- fulltext
Full Text 인덱스를 사용하여 데이터 Access (Only MyISAM)
- index_merge
동일한테이블에서 두 개 이상의 인덱스가 동시에 사용되는 경우 (fulltext 인덱스 제외)
인덱스병합 최적화가 적용되는 조인 타입
이경우, key 컬럼은 사용된 인덱스의 리스트를 나타낸다.
- unique_subquery
IN sub-query 에서 Unique 한 결과가 만들어 지는 경우
index lookup function이 사용됨 (서브쿼리 최적화)
- index_subquery
unique_subquery와 유사
IN sub-query 값이 Unique 하지 않음
- range
주어진범위 내의 row를 Scan하며 Access 해야 할 데이터의 범위에 크게 영향을 받음
키컬럼이 상수와 =, <>, >, >=, <, <=, IS NULL,<=>, BETWEEN 또는 IN 연산에 사용될 때 적용됨
- index
전체인덱스 Block을 스캔 하는 경우, 인덱스 Block을 스캔 한다는 것을 제외하면 Full Table Sacn(ALL)과같음
일반적인 경우 인덱스가 테이블보다 사이즈가 작기 때문에,ALL보다는 빠를 가능성이 높음
MySQL 은 쿼리에서 단일 인덱스의 일부분인 컬럼을 사용할 때 이 조인타입을 적용함
- ALL
젂체데이터 Block을 스캔 하는 경우 (Full Table Scan)
이전테이블과의 조인을 위해 풀스캔
(조인에 쓰인) 첫번 째 테이블이 고정이 아니라면 비효율적
대부분의경우에 아주 느린 성능을 보임
E.
possible_keys:
MySQL
옵티마이저가 쿼리처리를 위해 고려한 인텍스 후보
possible_keys 에 나타난 인덱스들이결과에 나타난 테이블 순서에서 실제 사용할 수 없을 수도 있음
F.
key:
MySQL
옵티마이저가 실제사용한 key(index)
G.
key_len:
MySQL
이 사용한 인덱스의 길이, key 컬럼 값이 NULL 이면 이 값도 NULL
key_len 값으로 MySQL 이 실제 복수 컬럼 키중 얼마나 많은 부분을 사용할 것인지 알 수 있음
H.
ref:
행을 추출하는데 키와 함께 사용된 컬럼이나 상수 값
I.
rows:
쿼리를 수행하기 위해 검색해야 할 Row의 개수 (옵티마이저연산에 따른 추정치)
J.
Extra:
MySQL
옵티마이저가 쿼리를 해석한 추가적인 정보를나타냄
- const row not found
대상 테이블이 empty 테이블인경우
-
Distinct
Distinct 쿼리를 수행하는 경우, 이미 처리한 값과 동일한 값을가짂 Row는 처리하지 않음
- Full scan on NULL key
Index lookup function이 사용되는 “IN (Subquery)” 쿼리에서 Outer Query에서 NULL 값이 공급되는 경우 발생
Index lookup 실패로 Full Table Scan이 발생할 수 있음
- Impossible HAVING
HAVING 절이 항상 False 인 경우, SELECT 처리하지 않음
- Impossible WHERE
WHERE 절이 항상 False 인 경우, SELECT 처리하지 않음
- Impossible WHERE noticedafter reading const tables
const/system 타입의 테이블을 읽은 후 WHERE 조건이 항상 False인 것을 확인
- No tables used
FROM 절에 테이블이 명시되지 않음, 혹은 FROM DUAL 구문을 사용
- Not exists
LEFT JOIN 형태의 Anti Join 쿼리를 Not Exists 형태로 최적화 하는 경우
(조건에 맞는 결과를 찾으면 추가 Join 처리하지 않음)
- range checked for eachrecord (index map: N)
조인처리시 적절한 인덱스가 없는 상황에서, 선행 테이블에서 공급되는 값에 따라 인덱스 사용을 검토할 수있는 경우
공급되는각각의 Row에 대해 range / index merge를검토
N 값은 어떤 인덱스가 검토되었는지 표시 (0x11011, 19 1, 4,5번 인덱스가 검토)
- Select tables optimizedaway
쿼리가 Aggregate(예: MAX) 함수만 포함하고 있는 경우
옵티마이저는인덱스 Lookup 후 1개의 결과만 리턴
- unique row not found
const row not found와 거의 유사
SELECT … FROM TABLE 쿼리에서 만족하는 row를 찾지못한 경우
- Using filesort
MySQL 이 정렬을 위해 추가적인 과정을 필요로 함(물리적인 정렬작업 수행)
- Using index
실제데이터 Block을 읽지 않고 인덱스 Block 만으로 결과를생성할 수 있는 경우 (Covering Index)
쿼리에서단일 인덱스된 컬럼들만을 사용하는 경우
- Using index for group-by
Using index와 유사하며, 데이터 Block을 읽지 않고 인덱스 Block 만으로 Group-By / Distinct 처리 (Covering Index)
Loose Index Scan 처리
- Using join buffer
Join 처리시 Join Buffer가 사용되었음을 의미
Join Buffer는 Join 처리를 위한 인덱스가 없을 때 사용됨
- Using sort_union(...),Using union(...), Using intersect(...)
Index Merge 수행, 두 개 이상의 인덱스를 동시에 사용하여처리
- Using temporary
쿼리처리를 위해 임시 테이블을 생성
group by, order by 컬럼이 각각 컬럼을 사용할 때 발생.group by 처리에 인덱스를 사용하지 못하는 경우 발생
- Using where
WHERE 절이 다음 조인에 사용될 행이나 클라이언트에게 돌려질 행을 제한하는 경우
l
extra 정리:
쿼리를 가능한 한 빠르게 하려면, Extra 값의Using filesort 나 Using temporary 에 주의해야 함
EXPLAIN 의 출력 내용 중 rows 컬럼값들을 곱해봄으로써 얼마나 효과적인 join 을 실행하고 있는지 알 수 있다 |
;)
게 시 판
현재 접속자 현황
김경훈 (admin)
