b

6장 실행계획 (6.2실행계획 분석, table,type,key 칼럼) 본문

RealMysql

6장 실행계획 (6.2실행계획 분석, table,type,key 칼럼)

dev.bistro 2012.10.25 20:30



6.2.3 table 칼럼

  실행계획읜 '테이블 기준', 테이블을 사용하지 않으면 NULL 을 표시한다.

  이 칼럼에 <union>처럼 <>로 명시되는 경우는 임시 테이블을 뜻한다. 



  ** MySQL은 다른DBMS와 달리 FROM에 사용된 서비쿼리는 반드시 별칭을 가져야 한다.

  ==> SELECT * FROM (SELECT de.emp_no FROM dept_emp de) 

  ==> Error Code: 1248   Every derived table must have its own alias


6.2.4 type칼럼 (중요)

  MySQL이 각 테이블을 어떤 방식으로 읽었는가를 뜻한다 (인덱스, 풀 테이블 스캔 등..)

  (MySQL 메뉴얼에서는 '조인 타입'으로 명명)

  ALL : 풀스캔, 나머지:index이용


  type종류 (위쪽일수록 빠르다)

  system : 레코드가 1건이하일경우만 존재 (MyISAM에서만 나옴, InnoDB는 ALL 또는 index)

  const : 건수 상관없이 유니크 키칼럼을 이용하며, 1건을 반환( 다른 DBMS = UNIQUE INDEX SCAN )

  eq_ref : 조인에서 첫 테이블의 칼럼값을 두번째 테이블의 유니크 키로 이용하고 1건만 반환

  ref : 조인 순서, 인덱스 상관없이 동등 조건으로 검색(1건이 아니어도 됨)

  == 인덱스의 분포도가 나쁘지 않다면 성능에 문제가 되지 않는다. 이 4가지에 대해서 튜닝에 신경을 작게써도 된다 ==


  range : 범위검색 < > IS NULL, BETWEEN, IN, LIKE 등     MySQL에서 우선 순위는 낮지만 성능은 보장된다

  index : 인덱스를 처음부터 끝까지 읽는 '인덱스 풀 스캔', 인덱스 자체가 원래 데이터보다 작아 풀 테이블 스캔보다는 빠르다.

  ALL : 풀 스캔, 가장 비효율적 (하지만 InnoDB는 한번에 여러 페이지를 읽는 Read Ahead 기능을 제공하므로, 잘못된 쿼리 튜닝보단 오히려 괜찮다. 무조건 사용하지 말라는게 아니다)


  **ALL**

  빠른 응답을 사용자에게 보내줘야하는 웹서비스와같은 OLTP에는 적합하지 않다.

  MySQL에서 '연속적으로 인접한 페이지가 연속해서 몇번읽히면 읽기 스레드가 최대 64개씩 동시에 읽는다 이것을 Read Ahead라고 한다


6.2.5 possible_keys

  최적비용을 계산하기 위해 사용할뻔한 인덱스목록들.. 걍 무시하자.


6.2.6 key (중요)

  passible_keys와 달리 '실제로 사용된 인덱스' 

  type:index_merge가 아니면 '무조건 테이블당 1개의 인덱스'

  type:ALL처럼 인덱스를 사용하지 못하면 NULL



6.2.7 key_len (중요)

  쿼리를 처리하기 위해 다중 칼럼으로 구성된 인덱스에서 몇개의 칼럼까지 사용했는지 알려준다.(정확하게는 인덱스의 몇바이트)

  CHAR(3바이트=12), INTEGER(4바이트=16)


6.2.8 ref 

  사용된 테이블, 칼럼명을 보여준다. (칼럼의 값을 변경하면 func로 노출된다)


6.2.9 rows

  실행 계획의 효율성 판단을 위해 예측한 레코드 건수를 보여준다.

  (만약 이 결과가 작다고 인덱스가 걸려있다면, 인덱스를 이용하겠지만, 아니면 내부적으로 풀 스캔을 이용할 것이다)


6.2.10 Extra

  중요한 내용을 표시(고정된 몇개의 문장중에서 몇개가 나옴)

  Impossible HAVING - Having을 만족하는 레코드 없을때 : 쿼리를 제대로 작성하지 못한 경우가 대부분, 점걸 필

  No tables used - from절이 없거나, from dual

  Select tables optimized away - SELECT MIN 이나, GROUp BY MIN()처럼 적절한 인덱스를 사용할 수 없고, 1건만 읽는 형태

  Using index; 데이터를 전혀 읽지 않고, 인덱스만으로 사용할 때

  Using intersect - 각각 인덱스를 사용하고 and로 연결

  Using union - 각각 인덱스를 사용하고 OR로 연결

  Using temporary - 중간 결과를 담기 위해 임시 테이블을 사용(이게 없더라도 내부적으로 임시 테이블을 사용할 경우가 많다)

6.2.11 explain extended 

  필터링 정보가 추가적으로 나옴 이 명령이후 'show warnings'를 치면 분석후 실행된 재조합 쿼리를 보여준다. (표준SQL은 아니다)


  


Extra의 using index, type의 index(풀스캔)는 완전히 다르다



0 Comments
댓글쓰기 폼