참고 : real mysql
쿼리 실행 절차
- SQL 파싱 -> 파스 트리
- 실행 계획 수립
- 실행
실행 계획 분석
- EXPLAIN 키워드 사용.
SELECT문에 대해서만 사용 가능
실행 계획에서 위에 표시된 결과일수록 OUTER 테이블(먼저 접근한 테이블)
실행 계획에 표시되는 컬럼들
id 컬럼
단위 SELECT 쿼리마다 부여되는 식별자
select_type 컬럼
각 단위 SELECT 쿼리의 타입을 알려주는 컬럼
-
SIMPLE
단순한 SELECT 쿼리 -
PRIMARY
UNION이나 서브쿼리가 포함된 쿼리의 가장 바깥쪽 쿼리는 PRIMARY로 표시
EXPLAIN
SELECT pd.id AS productId
FROM product pd
WHERE pd.id > (
SELECT MAX(pd2.id)
FROM product pd2
WHERE pd2.category_id = 1
GROUP BY pd2.category_id
);
-
SUBQUERY
WHERE절에 사용된 서브쿼리를 의미(nested query,inline view는 제외) -
UNION
UNION으로 결합하는 SELECT 쿼리 중 첫번째를 제외한 것
-
DERIVED
서브쿼리가 FROM 절에 사용된 경우(inline view)
단위 SELECT의 실행 결과를 메모리나 디스크에 임시 테이블로 만듦.
type 컬럼
MySQL 서버가 각 테이블의 레코드를 어떤 방식으로 읽었는지(테이블 접근 방식)
성능 : system, const, eq_ref, ref > range >> index >> ALL
-
const (상수)
where절에 pk나 unique key로 '=' 비교했을 때
즉, 유일함이 보장되어 레코드를 다 읽을 필요가 없는,
반드시 1건을 반환하는 쿼리 (index unique scan) -
eq_ref
조인할 때 처음 읽은 테이블 컬럼 값을 그 다음 inner 테이블의 후보키(unique & not null) 검색 조건에 사용할 때. -
ref
조인할 때 Equal('=') 조건으로 하면 ref 접근 방법이 사용됨.
물론 다음 테이블과 조인 조건으로 후보키인 행에 대해서 Equal 비교하면 eq_ref가 될 것.
pk에 대해서 Equal 조건을 명시하면 const로 표시될 것. -
range
<,>,IS NULL , BETWEEN,IN,LIKE 등을 이용해서 인덱스를 검색할 때 사용
const,eq_ref,ref보단 느리지만 충분히 빠른 접근 방법 -
index
인덱스 풀 스캔. 비효율적.
대신 LIMIT 조건과 함께 쓰였다면 range랑 거의 동일함. -
ALL
테이블 풀 스캔. 가장 비효율적인 방법.
대용량 DB에서는 또 다른 얘기?
possible_keys 컬럼
옵티마이저가 실행 계획을 만들기 위해 후보로 선택했던 접근 방식에서 사용되는 인덱스의 목록
key 컬럼
실행 계획에서 실제로 사용한 인덱스
key_len 컬럼
ref 컬럼
Equal 비교 조건으로 어떤 컬럼이 제공됐는지.
후보키급이 비교조건으로 사용되면 const로 표시되는 듯하다.
rows 컬럼
실행 계획에서 예측한 각 단위 쿼리에서 디스크로부터 읽어야 하는 레코드의 수
디스크 읽기니까 스토리지 엔진의 영역
filtered 컬럼
각 단계에서 MySQL엔진에 의해 필터링되고 레코드가 얼마나 남았는지의 비율.
실제 값이 아니라 통계 정보로 부터 예측된 값.
Extra 컬럼
로그처럼 쿼리 실행 후 특이점에 대해 알려줌.
쿼리 성능과 관련된 정보들이 많이 있어 중요하다고 함.
주요 처리 방식
ORDER BY(정렬) 처리
드라이빙 테이블이 중요.
스트리밍 vs 버퍼링
- 인덱스를 사용할 수 있으면
인덱스를 사용해서 정렬 - 인덱스를 사용할 수 없다면
a. 드라이빙 테이블만 정렬 (using filesort)
b. 임시 테이블에서 정렬 (using temporary)
테이블 조인
