mojh7
commented
1 year ago 10.3.12.21 Using filesort
ORDER BY 처리가 인덱스를 사용하지 못할 때만 해당 메시지가 표시됨
조회된 레코드를 정렬용 메모리 버퍼에 복사해 퀵 소트 또는 힙 소트 알고리즘을 이용해 정렬을 수행하게 된다는 의미
EXPLAIN
SELECT * FROM employees
ORDER BY last_name DESC;last_name 칼럼에는 인덱스가 없으므로 이 쿼리의 정렬 작업을 처리하기 위해 인덱스 이용 불가능
옵티마이저는 레코드를 읽어서 소트 버퍼에 복사하고, 정렬해서 결과를 클라이언트에게 보냄
Extra 칼럼에 해당 메시지가 출력되는 쿼리는 많은 부하를 일으키므로 가능한 쿼리를 튜닝하거나 인덱스를 생성하는 것이 좋다
10.3.12.22 Using index(커버링 인덱스)
데이터 파일을 전혀 읽지 않고 인덱스만 읽어서 쿼리를 모두 처리할 수 있을 때 표시됨
인덱스를 이용해 처리하는 쿼리에서 가장 큰 부하를 차지하는 부분은
인덱스 검색에서 일치하는 키 값들의 레코드를 읽기 위해 데이터 파일을 검색하는 작업이다
- 최악의 경우 레코드 한 건 한 건마다 디스크도 한 번씩 읽어야 할 수도 있다
476p
EXPLAIN
SELECT first_name, birth_date
FROM employees
WHERE first_name BETWEEN 'Babette' AND 'Gad';만약 where 조건절에 일치하는 레코드는 5건이지만, 대략 5만건을 조회 했었다고 가정하면
first_name 칼럼에 생성된 인덱스를 이용해 일치하는 레코드 5만여 건을 검색하고 각각 birth_date 칼럼의 값을 읽기 위해 각 레코드가 저장된 데이터 페이지를 5만여 번 읽어야 됨
그래서 옵티마이저는 인덱스를 사용하는 것보다 풀 테이블 스캔으로 처리하는 편이 더 효율적이라고 판단해서 type에 ALL로 표시(477p)
- 인덱스 레인지 스캔은 랜덤 I/O, 테이블 풀 스캔은 순차 I/O
인덱스 만으로 쿼리를 수행할 수 있을 때 Extra 칼럼의 Using index라는 메시지가 출력되고, 이렇게 인덱스만으로 처리되는 것을 커버링 인덱스라고 불린다
인덱스 레인지 스캔을 사용하지만 쿼리의 성능이 만족스럽지 못한 경우 커버링 인덱스로 쿼리를 변경해 큰 성능 향상을 볼 수 있다(수십 배에서 수백 배 까지 날 수 있음)
InnoDB 모든 테이블은 클러스터링 인덱스로 구성돼 있고, 모든 세컨더리 인덱스는 데이터 레코드의 주솟값으로 프라이머리 키 값을 가진다
책 예제에서 first_name 칼럼만으로 인덱스를 만들어도 이 인덱스에 결국 emp_no 칼럼이 같이 저장되는 효과를 낸다
이러한 특징으로 쿼리가 커버링 인덱스로 처리될 가능성이 꽤 높다
인덱스 풀 스캔을 실행할 때도 커버링 인덱스로 처리될 수 있는데, 아닐 때 보다 훨씬 빠르게 처리됨
주의
Extra 칼럼에 Using index는 커버링 인덱스 사용한 것
type 칼럼의 index는 인덱스 풀 스캔으로 처리하는 방식을 의미
커버링 인덱스는 실행 계획에 type에 관계없이 사용될 수 있다
헷갈릴 수도 있다
10.3.12.23 Using index condition
옵티마이저가 인덱스 컨디션 푸시 다운 최적화를 사용하면 해당 메시지가 표시됨
danbi5228
다음 스터디
2022-11-24 pm 10:20
학습 범위
정리 범위