4.3.10 Extra컬럼(2)

앞의 글에 이어서 실행계획의 Extra컬럼에 대해서 정리하는 두번째 글입니다.

 

Using index

데이터 파일을 전혀 읽지 않고 인덱스만 읽어서 쿼리를 모두 처리할 수 있을때 표시됩니다.

MariaDB [employees]> explain
    -> select first_name from employees where first_name between 'Balette' and 'Gad';

+------+-------------+-----------+-------+---------------+--------------+---------+------+-------+--------------------------+
| id   | select_type | table     | type  | possible_keys | key          | key_len | ref  | rows  | Extra                    |
+------+-------------+-----------+-------+---------------+--------------+---------+------+-------+--------------------------+
|    1 | SIMPLE      | employees | range | ix_firstname  | ix_firstname | 44      | NULL | 99212 | Using where; Using index |
+------+-------------+-----------+-------+---------------+--------------+---------+------+-------+--------------------------+
1 row in set (0.008 sec)

위의 쿼리를 보면 필요한 컬럼이 모두 인덱스에 있으므로 나머지 컬럼이 저장된 데이터 파일을 일거 올 필요가 없습니다.

접근방법(실행계획의 type컬럼)이 eq_ref,ref,range,index_merge,index 등과 같이 인덱스를 사용하는 실행계획에서는 모두 Extra컬럼에 Using index가 표시될 수 있습니다. 즉 인덱스 레인지 스캔을 사용할 때만 커버링 인덱스로 처리되는 것은 아닙니다. 인덱스 풀 스캔을 실행할 때도 커버링 인덱스로 처리될 수있는데 이때도 똑같은 인덱스 풀 스캔 접근방법이라면 커버링 인덱스가 아닌 경우보다 훨씬 빠르게 처리됩니다.

 

Using index for group-by

Group by 처리가 인덱스(B-tree인덱스에 한해)를 이용하면 정렬된 인덱스 컬럼을 순서대로 읽으면서 그룹핑 작업만 수행합니다. 이렇게 Group by 처리에 인덱스를 이용하면 레코드의 정렬이 필요하지 않고 인덱스의 필요한 부분만 읽으면 되기 때문에 상당히 효율적이고 빠르게 처리됩니다. Group by 처리가 인덱스를 이용할 때 쿼리의 실행계획에서는 해당 메세지가 표시됩니다.

MariaDB [employees]> explain
    -> select emp_no,min(from_date) as first_changed_date,max(from_date) as last_changed_date from salaries group by emp_no;
+------+-------------+----------+-------+---------------+---------+---------+------+--------+--------------------------+
| id   | select_type | table    | type  | possible_keys | key     | key_len | ref  | rows   | Extra                    |
+------+-------------+----------+-------+---------------+---------+---------+------+--------+--------------------------+
|    1 | SIMPLE      | salaries | range | NULL          | PRIMARY | 4       | NULL | 691829 | Using index for group-by |
+------+-------------+----------+-------+---------------+---------+---------+------+--------+--------------------------+
1 row in set (0.007 sec)

 

Using join buffer(Block Nested Loop),Using join buffer(Batched key Access)

드리븐 테이블의 비효율적인 검색을 보완하기 위해 mariaDB서버는 드라이빙 테이블에서 읽은 레코드를 임시 공간에 보관해두고 필요할 때 재사용할 수 있게 해줍니다. 읽은 레코드를 임시로 보관해두는 공간을 조인버퍼라고 하며 조인버퍼가 사용되는 실행계획의 Extra컬럼에는 해당 메시지가 표시됩니다.

 

Using sort_union, Using union, Using intersect, Using sort_intersection

쿼리가 Index_merge 접근방식으로 실행되는 경우에는 2개 이상의 인덱스가 동시에 사용될 수 있습니다. 이 때 실행계획의 Extra컬럼에는 두 인덱스로부터 읽은 결과를 어떻게 병합했는지 조금 더 상세하게 설명하기 위해 다음 메세지를 출력합니다.

 

Using temporary

쿼리의 실행계획에서 해당 메세지가 표시되면 임시 테이블을 사용한 것입니다. 이때 사용된 임시 테이블이 메모리에 생성됐었는지 디스크에 생성됐었는지는 실행계획만으로 판단할 수 없습니다.

 

Using where

MariaDB는 내부적으로 MariaDB엔진과 스토리지 엔진이라는 두개의 레이어로 나눠서 볼 수 있습니다. MariaDB 엔진 레이어에서 별도의 가공을 해서 필터링작업을 처리한 경우에만 Extra 컬럼에 Using where 코멘트가 표시됩니다.

 

Using where with pushed condition

Condition push down이 적용됐음을 의미하는 메시지입니다. 

 

Deleteing all rows

스토리지 엔진의 핸들러 차원에서 테이블의 모든 레코드를 삭제하는 기능을 제공하는 스토리지 엔진 테이블인 경우 Extra필드에 Deleteing all rows 문구가 표시됩니다.

Where 절 없는 DELETE 문장의 실행계획에서 자주 표시되며 이 문구는 테이블의 모든 레코드를 삭제하는 핸들러 기능을 한번 호출함으로써 처리되었다는 것을 의미합니다.

 

FirstMatch(tbl_name)

MySQL 5.5나 MariaDB5.5에서 추가된 IN-to-EXISTS 최적화 방식에 대해서 이름만 부여된 것입니다. Firstmatch(departments)는 괄호 안의 테이블이 외부 테이블임을 나타냅니다.

 

LooseScan(m..n)

MariaDB 5.3과 MySQL5.6이후 버전에서 서브 쿼리를 최적화하기 위한 여러 가지 해결책 중 하나로, IN(subquery)형태의 쿼리에서 서브 쿼리의 결과가 중복된 레코드를 만들어 낼 가능성이 있을때 사용되는 최적화 방법입니다.

LooseScan은 서브 쿼리의 내용을 Loose index Scan 접근 방법으로 읽어서 중복된 레코드를 제거할 수 있는 경우 사용되는 최적화방법입니다.

 

Materialize,Scan

서브 쿼리의 빠른 처리를 위한 또 다른 최적화 방법 중 하나인 구체화가 사용되었다는 것을 의미하는 문구입니다.

 

Start materialize,End materialize,Scan

Extra필드에 Materialize가 표시되는 경우와 동일합니다.

 

Start temporary,End temporary

서브 쿼리의 최적화 방법 중에서 또 다른 방법 중 하나로 Duplicate Weedout이라는 것이 있는데 이 최적화 방법이 사용된 경우에는 Extra필드에 Start temporary와 End temporary문구가 출력됩니다.

Duplicate Weedout 최적화는 IN(subquery)형태의 쿼리 문장에서 서브 쿼리를 먼저 조회해서 외부 쿼리의 테이블과 조인한 결과를 임시 테이블에 저장하고 중복된 레코드를 제거하는 것을 말합니다. 마치 우리가 직접 IN(subquery)형태의 쿼리를 조인으로 풀어쓴 다음 GROUP BY로 중복된 레코드를 제거하는 것과 같이 작동합니다.

 

Using index condition

WHERE 조건절을 가진 쿼리가 실행될 때, WHERE 절의 조건이 인덱스를 사용할 수 있다면 먼저 인덱스를 읽어서 조건에 부합되는지 여부를 판단하고 필요 시 데이터 파일의 레코드를 읽게됩니다. 이 최적화를 인덱스 컨디션 푸시다운이라고 합니다.

 

Rowid-ordered scan,Key-ordered scan

멀티 레인지 리드를 사용할 때 표시됩니다.

인덱스를 통해서 WHERE 조건에 일치하는 레코드를 어느 정도 읽은 후 프라이머리 키 값으로 모두 정렬한 다음 실제 데이터 파일에서 나머지 칼럼들에 대한 읽기를 실행합니다. 이렇게 함으로써 랜덤 데이터파일 읽기 횟수를 줄일 수 있습니다.

 

No matching rows after partition pruning

MariaDB에서는 파티션 테이블에 대한 검색을 수행할 대 파티션 키 컬럼에 대한 조건을 기준으로 검색할 필요가 없는 파티션을 작업 목록에서 제거하는 작업을 수행합니다. 이 작업을 파티션 프루닝이라고 표현하는데 MariaDB의 옵티마이저가 쿼리의 실행 계획을 수립할 때 WHERE조건에 부합되는 파티션이 존재하지 않는 경우에는 해당 문구를 표시합니다.

해당 문구 표시시, 조건에 부합되는 레코드를 찾을 수 없다는 의미이므로 WHERE 조건절을 다시 컴토해 보는것이 좋습니다.

 

출처 : Real MariaDB