책너두 6기 48일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.485 ~ p.490 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.27 Using MRR MRR(Multi Range Read) 최적화는 여러 개의 키 값을 한 번에 스토리지 엔진으로 전달하고, 스토리지 엔진은 넘겨받은 키 값들을 정렬해서 최소한의 페이지 접근만으로 필요한 레코드를 읽을 수 있게 한다. 10.3.12.28 Using sort_union(…), Using union(…), Using intersect(…) 쿼리가 index_merge 접근 방법으로 실행되는 경우에는 2개 이상의 인덱스가 동시에 사용될 수 있다. 이 때 두 인덱스로부터 읽은 결과를 어떻게 병합했는지 조금 더상세하기 설명하기 위해 3개 중에서 하나의 메시지를 출력한다. ...
책너두 6기 47일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.480 ~ p.484 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.13 Using index condition 인덱스 컨디션 푸시 다운(Index condition pushdown) 최적화를 사용하면 표시된다. 10.3.12.14 Using index for group-by GROUP BY 처리가 인덱스를 이용할 때 표시 10.3.12.14.1 타이트 인덱스 스캔(인덱스 스캔)을 통한 GROUP BY 처리 AVG(), SUM(), COUNT() 처럼 조회하려는 값이 모든 인덱스를 다 읽어야 할 때는 필요한 레코드만 듬성듬성 읽을 수가 없다. 이럴 떄는 메시지가 출력되지 않는다. ...
책너두 6기 46일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.473 ~ p.479 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.19 Start temporary, End temporary 세미 조인 최적화 중에서 Duplicate Weed-out 최적화 전략이 사용되면 표시된다. 10.3.12.20 unique row not found 두 개의 테이블이 각각 유니크(프라이머리키 포함) 칼럼으로 아우터 조인을 수행하는 쿼리에서 아우터 테이블에 일치하는 레코드가 존재하지 않을 때 10.3.12.21 Using filesort ORDER BY를 처리하기 위해 인덱스를 이용할 수도 있지만 적절한 인덱스를 사용하지 못할 때는 MySQL 서버가 조회된 레코드를 다시 한번 정렬해야 한다. ORDER BY 처리가 인데스를 사용하지 못할 때만 표시된다. ...
책너두 6기 45일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.466 ~ p.472 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.14 Plan isn’t ready yet EXPLAIN FOR CONNECTION 명령은 MySQL 옵티마이저가 의도된 인덱스를 사용하지 못해서 풀 스캔을 한다거나 잘못된 실행 계획을 선탣한 것이 아닌지 확인할 떄 유용하게 사용할 수 있는 명령이다. 이 명령을 실행했을 때 Extra 칼럼에 “Plan is not ready yet"이라는 메시지가 표시되면, 해당 커넥션에서 아직 쿼리의 실행 계획을 수립하지 모 ㅅ한 상태에서 EXPLAIN FOR CONNECTION 명령이 실행된 것을 의미한다. 따라서, 잠시 후 실행하면 된다. ...
책너두 6기 44일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.458 ~ p.465 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.4 FirstMatch FirstMatch 전략이 사용되면 출력된다. 10.3.12.5 Full scan on NULL key SQL 표준에서는 NULL을 “알 수 없는 값"으로 정의하고 있으며, NULL에 대한 연산의 규칙까지 정의하고 있다. 연산을 수행하기 위해 이 조건은 다음과 같이 비교돼야 한다. 서브쿼리가 1건이라도 결과 레코드를 가진다면 최종 비교 결과는 NULL 서브쿼리가 1건도 결과 레코드를 가지지 않는다면 최종 비교 결과는 FALSE 10.3.12.6 Impossible HAVING 쿼리에 사용된 HAVING 절의 조건을 만족하는 레코드가 없을 때 실행 계획의 Extra칼럼에는 “Impossible HAVING” 키워드가 표시된다. ...
책너두 6기 43일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.449 ~ p.457 내용정리 10 실행계획 10.3 실행계획분석 10.3.6 possible_keys 칼럼 MySQL 옵티마이저는 쿼리를 처리하기 위해 여러 가지 처리 방법을 고려하고 그중에서 비용이 가장 낮을 것으로 예상하는 실행 계획을 선택해 쿼리를 실행한다. 그런데 possible_keys 칼럼에 있는 내용은 옵티마이저가 최적의 실행 계획을 만들기 위해 후보로 선정했던 접근 방법에서 사용되는 인덱스의 목록일 뿐이다. 즉, 말 그대로 “사용될 법했던 인덱스의 목록"이다. 10.3.7 key 칼럼 최종 선택된 실행 계획에서 사용하는 인덱스를 의미 ...
책너두 6기 42일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.442 ~ p.448 내용정리 10 실행계획 10.3 실행계획분석 10.3.5 type 칼럼 10.3.5.6 ref_or_null ref 접근 방법과 같은데, NULL 비교가 추가된 형태 10.3.5.7 unique_subquery WHERE 조건절에서 사용될 수 있는 IN(subquery) 형태의 쿼리를 위한 접근 방법 10.3.5.8 index_subquery IN 연산자의 특성상 IN(subquery) 또는 IN(상수 나열) 형태의 조건은 괄호 안에 있는 값의 목록에서 중복된 값이 먼저 제거된다. unique_subquery는 중복된 값을 만들어내지 않지만, IN(subquery)에서 subquery가 중복된 값을 반환할 때, 인덱스를 이용해서 제거할 수 있으면 이 접근 방법이 사용된다. ...
책너두 6기 41일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.434 ~ p.441 내용정리 10 실행계획 10.3 실행계획분석 10.3.5 type 칼럼 type 이후의 칼럼은 MySQL 서버가 각 테이블의 레코드를 어떤 방식으로 읽었는지를 나타낸다. 인덱스를 사용했는지, 처음부터 풀 테이블 스캔으로 읽었는지 등등.. 따라서 반드시 체크해야할 중요한 정보다. 10.3.5.1 system 레코드가 1건만 존재하는 테이블 또는 한 건도 존재하지 않는 테이블을 참조하는 형태의 접근 방법 10.3.5.2 const 테이블의 레코드 건수와 관계없이 쿼리가 프라이머리 키나 유니크 키 칼럼을 이용하는 WHERE 조건절을 가지고 있으며, 반드시 1건으 ㄹ반환하는 쿼리의 처리 방식 ...
책너두 6기 40일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.429 ~ p.433 내용정리 10 실행계획 10.3 실행계획분석 10.3.3 table 칼럼 MySQL 서버의 실행 계획은 단위 SELECT쿼리 기준이 아니라 테이블 기준으로 표시된다. “<>” 으로 둘러싸인 이름이 명시되는 테이블은 임시 테이블을 의미한다. 10.3.4 paritions 칼럼 EXPLAIN 명령으로 파티셔 관련 실행 계획까지 모두 확인할 수 있다.
책너두 6기 39일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.419 ~ p.428 내용정리 10 실행 계획 10.3 실행 계획 분석 10.3.2 select_type 칼럼 각 단위 SELECT 쿼리가 어떤 타입의 쿼리인지 표시되는 칼럼이다. 다음 값들이 출력된다. 10.3.2.1 SIMPLE UNION이나 서브쿼리를 사용하지 않은 단순한 SELECT쿼리인 경우 출력 10.3.2.2 PRIMARY UNION이나 서브쿼리를 가지는 SELECT 쿼리의 실행 계획에서 가장 바깥쪽(Outer)에 있는 단위 쿼리 10.3.2.3 UNION UNION으로 결합하는 단위 SELECT 쿼리 가운데 첫 번쨰를 제외한 두 번째 이후 단위 SELECT 쿼리 ...