일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 카프카
- kafkastreams
- spring-batch
- aws
- confluent
- coursera
- enablekafkastreams
- 한빛미디어
- Elk
- Logstash
- kafka streams
- avo
- Spring
- spring-cloud-stream
- Kafka
- play framework
- Elasticsearch
- gradle
- statestore
- spring-kafka
- 플레이 프레임워크
- reactive
- scala
- Slick
- RabbitMQ
- kafka interactive query
- scala 2.10
- schema registry
- kafkastream
- springboot
- Today
- Total
b
6장 실행계획 (6.2실행계획 분석, table,type,key 칼럼) 본문
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(풀스캔)는 완전히 다르다
'RealMysql' 카테고리의 다른 글
7. 쿼리 작성 및 최적화 (ANSI SQL명령) (0) | 2012.11.12 |
---|---|
6장 실행계획 (6.3.6 테이블 조인) (0) | 2012.11.09 |
6장 실행계획 (6.2 MySQL의 주요 처리 방식 - order by 등등) (0) | 2012.11.08 |
6장 실행계획 (6.2실행계획 분석, id칼럼, select_type칼럼) (0) | 2012.10.22 |
6장 실행 계획 ( 6.1 개요 ) (0) | 2012.10.19 |