본문 바로가기
mysql

mysql explain 정보 보는방법

by [김경민]™ ┌(  ̄∇ ̄)┘™ 2013. 4. 27.
728x90

출처 : http://laydios.egloos.com/1542611

 

Explain 정보보는법

인덱스가 적절히 사용되고 있는지 검토
나열된 순서는 MYSQL 이 쿼리처리에 사용하는 순서대로 출력


EXPLAIN 의 각 행 설명


1. id : SELECT 번호, 쿼리내의 SELECT 의 구분번호


2. select_type: SELECT 의 타입

 1) SIMPLE: 단순 SELECT (UNION 이나 서브쿼리를 사용하지 않음)
 2) PRIMARY: 가장 외곽의 SELECT
 3) UNION: UNION 에서의 두번째 혹은 나중에 따라오는 SELECT
 4) DEPENDENT UNION: UNION 에서의 두번째 혹은 나중에 따라오는 SELECT, 외곽쿼리에 의존적
 5) UNION RESULT: UNION 의 결과물
 6) SUBQUERY: 서브쿼리의 첫번째 SELECT
 7) DEPENDENT SUBQUERY: 서브쿼리의 첫번째 SELECT, 외곽쿼리에 의존적
 8) DERIVED: SELECT 로 추출된 테이블 (FROM 절 내부의 서브쿼리)


3. table: table명


4. type: 조인타입, 우수한 순서대로... 뒤로갈수록 나쁜 조인형태

 1) system
 테이블에 단 하나의 행만 존재(시스템 테이블). const join 의 특수한 경우
 2) const
 많아야 하나의 매치되는 행만 존재할 때
 PRIMARY KEY 나 UNIQUE index 를 상수와 비교할 때
 각 컬럼값은 나머지 연산에서 상수로 간주, 처음 한번만 읽어들이면 되므로 매우 빠름
 3) eq_ref
 조인수행을 위해 각 테이블에서 하나씩의 행만이 읽히는 경우
 조인연산에 PRIMARY KEY 나 UNIQUE index 인덱스가 사용되는 경우
 인덱스된 컬럼이 = 연산에 사용되는 경우
 4) ref
 이전 테이블과의 조인에 사용될 매치되는 인덱스의 모든행이 이 테이블에서 읽혀질 때
 leftmost prefix 키만을 사용하거나 사용된 키가 PRIMARY KEY 나 UNIQUE 가 아닐때
 (즉 키값으로 단일행을 추출할수 없을때)
 사용된 키가 적은수의 행과 매치되면 이것은 적절한 조인 타입
 ref 는 인덱스된 컬럼과 = 연산에서 사용됨
 5) ref_or_null
 ref 와 같지만 NULL 값을 포함하는 행에대한 검색이 수반될 때
 서브쿼리 처리에서 대개 사용됨
 6) index_merge
 인덱스 병합 최적화가 적용되는 조인 타입
 이 경우, key 컬럼은 사용된 인덱스의 리스트를 나타내며
 key_len 컬럼은 사용된 인덱스중 가장 긴 key 명을 나타냄
 7) unique_subquery
 몇몇 IN 서브쿼리 처리에서 ref 타입대신 사용됨
 unique_subquery 는 성능향상을 위해 서브쿼리를 단순 index 검색 함수로 대체함
 8) index_subquery
 unique_subquery 와 마찬가지로 IN 서브쿼리를 대체
 단, 서브쿼리에서 non-unique 인덱스가 사용될때 동작 함
 9) range
 인덱스를 사용하여 주어진 범위 내의 행들만 추출
 key 컬럼: 사용된 인덱스
 key_len: 사용된 가장 긴 key 부분
 ref 컬럼: 이 타입의 조인에서 NULL
 키 컬럼이 상수와 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN 또는 IN 연산에 사용될때 적용됨
 10) index
 인덱스가 스캔된다는걸 제외하면 ALL 과 같음
 일반적으로 인덱스 파일이 데이타파일보다 작기 때문에 ALL 보다는 빠름
 MySQL 은 쿼리에서 단일 인덱스의 일부분인 컬럼을 사용할때 이 조인타입을 적용함
 11) ALL
 이전 테이블과의 조인을 위해 풀스캔
 (조인에 쓰인) 첫번째 테이블이 고정이 아니라면 비효율적
 대부분의 경우에 아주 느린 성능

정리: system - const - eq_ref - ref - ref_or_null - index_mergy - unique_subquery - index_subquery - range - index - ALL


5. possible_keys: MySQL 이 해당 테이블의 검색에 사용할수 있는 인덱스들
possible_keys 에 나타난 인덱스들이 결과에 나타난 테이블 순서에서 실제 사용할 수 없을수도 있음


6. key: MySQL 이 실제 사용한 key(index)


7. key_len: MySQL 이 사용한 인덱스의 길이, key 컬럼값이 NULL 이면 이값도 NULL
key_len 값으로 MySQL 이 실제 복수컬럼 키중 얼마나 많은 부분을 사용할 것인지 알 수 있음


8. ref: 행을 추출하는데 키와 함께 사용된 컬럼이나 상수값


9. rows: 쿼리 수행에서 MySQL 이 예상하는 검색해야할 행수


10. Extra: MySQL 이 쿼리를 해석한 추가적인 정보를 나타냄
 1) Distinct
 MySQL 이 매치되는 첫행을 찾는 즉시 검색을 중단한다는 의미
 2) Not exists
 MySQL 이 LEFT JOIN 을 수행함에 매치되는 한 행을 찾으면 더이상 매치되는 행을 검색x
 3) range checked for each record (index map: #)
 MySQL 이 사용할 좋은 인덱스가 없음 의미
 4) Using filesort
 MySQL 이 정렬을 위해 추가적인 과정을 필요로 함
 5) Using index
 컬럼정보가 실제 테이블이 아닌 인덱스트리에서 추출,
 쿼리에서 단일 인덱스된 컬럼들만을 사용하는 경우
 6) Using temporary
 MySQL 이 결과의 재사용을 위해 임시테이블을 사용,
 쿼리 내에 GROUP BY 와 ORDER BY 절이 각기 다른 컬럼을 사용할때 발생
 7) Using where
 WHERE 절이 다음 조인에 사용될 행이나 클라이언트에게 돌려질 행을 제한하는 경우
 테이블의 모든 행을 검사할 의도가 아니면 ALL 이나 index 라면 쿼리사용이 잘못된 것임
 8) Using sort_union(...) , Using union(...) , Using intersect(...)
 9) Using index for group-by
 Using index 와 접근방식이 같으며, 추가적인 디스크 접근 없이 GROUP BY 나 DICTINCT 쿼리에 사용된 모든 컬럼에 대한 인덱스를 찾았음을 의미


 

정리:
쿼리를 가능한 한 빠르게 하려면, Extra 값의 Using filesort 나 Using temporary 에 주의해야 함
EXPLAIN 의 출력내용중 rows 컬럼값들을 곱해봄으로써 얼마나 효과적인 join 을 실행하고 있는지 알 수 있다

 

728x90

댓글