6장 실행계획 (6.2실행계획 분석, id칼럼, select_type칼럼)

6.2 실행 계획 분석

   사용 문법 : EXPLAIN SELECT 쿼리 문장

   사용 예제 : EXPLAIN SELECT e.emp_no FROM `employees` e, `salaries` s LIMIT 10;

   결과 : 

     각 라인은 쿼리 문장에서 사용된 테이블(임시포함) 갯수만큼 출력된다.

     실행순서는 위-> 아래(UNION, SUB쿼리는 순서대로가 아닐 수 있다)

   특징 :

     다른DBMS아 달리 실행 계획을 산출하기 위해 쿼리 일부분을 직접 실행할때도 있다

     ->실행계획 조회도 느릴수 있다.

     ->UPDATE, INSERT, DLETE는 실행계획조회를 할 수 없다. (WHERE-SELECT를 이요해서하라)

6.2.1 id 칼럼

 -하나의 SELECT는 다시 1개 이상의 SUB- SELECT 문장을 포함 할 수 있다. 

 - 각 SELECT절을 "단위 쿼리"로 하고 하나의 단위 쿼리당 1개의 id값을 가진다.

 - 여러곳에 조인되는 1개의 테이블은 1개의 id를 가진다.

6.2.2 select_type 칼럼

 - 각 단위쿼리가 어떤 타입인지 표현하는 칼럼

 -- SIMPLE : 단순 SELECT (조인 포함), 무조건 0/1개만 존재한다.

 -- PRIMARY : 실행 계획에서 가장 바깥(outer)에 있는 단위 쿼리오직 1개만 존재한다.

 -- UNION : UNION으로 결합하는 단위 쿼리중 첫번째를 제외한 두번째 이후 단위 쿼리

 -- DEPENDENT UNION : UNION 단위쿼리가, 외부의 값을 참조해서 처리될때 가지는 type

 **** 중요 ***

 보통은 내부쿼리(inner)를 먼저 수행하며, 이것이 반대보다 빠르다. 

 단! dependent union은 내부쿼리가 먼저 실행될 수 없으며, 이러한 경우에는 비효율적인 경우가 많다.

 *************

 -- UNION RESULT : UNION 결과를 담는 테이블. (실제 단위쿼리가 아니라 id는 부여되지 않고 UNION, UNION ALL 의 결과물을 임시 저장하는 테이블)

 -- SUBQUERY : FROM절의 서브쿼리는 'DERIVED', 그외의 서브쿼리는 'SUBQUERY'로  표시

 -- DEPENDENT SUBQUERY : 서브쿼리가 outer쿼리를 참조할 경우 (역시 느릴 경우가 많다)

 -- DERIVED : 서브쿼리가 FROM절에 사용될 경우 "항상" ::=> DERIVED는 단위쿼리 결과를 메모리나 디스크에 임시테이블을 생성하는것을 의미(=파생테이블), 파생테이블에는 인덱스가 전혀없어, 성능상 불리

 --- 매우 안좋은 예 : EXPLAIN SELECT * FROM (SELECT de.emp_no FROM dept_emp de) tb, employees e WHERE e.emp_no = tb.emp_no;

 -- UNCACHEABLE : 캐시를 사용하지 못하는 요소 - 사용자변수가 사용된 경우 등...

** 오늘의 중요한것들

1. select_type DERIVED것이 있는지 확인하고, 이를 서브쿼리보단 조인으로 해결하는 것을 권장