minkukjo
commented
2 years ago MySQL의 풀 테이블 스캔
- MySQL의 데이터베이스는 한 번에 몇 개씩 페이지를 읽어 올지 설정 하는 기능이 없다
- 대신 innodb 스토리지 엔진에서 특정 테이블에 연속 데이터 페이지를 읽으면 백그라운드 스레드에서 Read Ahead 작업이 자동으로 시작 된다
- 이는 백그라운드 쓰레드가 한 번에 내게 또는 여덟 개씩 페이지를 읽으면서 그 페이지들을 버퍼풀에 미리 가져다 두는 것을 의미한다 (최대 64개)
- 결국 포그라운드 쓰레드는 미리 버퍼풀에 준비된 데이터를 가져다 쓰기 때문에 쿼리가 상당히 빨리 처리 된다
- 이는 풀인덱 스캔에서도 마찬가지로 적용된다
- select count(*) from table은 풀 인덱스 스캔을 한다. ( 단순히 레코드 건수만 필요로 하기 때문에 풀 인덱스 스캔의 비용이 더 싸기에 디스크 읽기 횟수를 줄일 수 있다)
- 그러나 select * from table은 모든 컬럼이 필요하므로 풀 테이블 스캔을 한다
Filesort
- 파일 소트는 데이터가 작을 때는 분명 장점이 있긴 하다
- 그러나 파일 소트로 인한 정렬 과정에서 디스크 리드 라이트가 많이 일어나게 되고 이로 인해 좋지 않은 성능을 내게 된다
- 이를 소트 버퍼 크기를 조정해서 해결해 볼 수 있을 것 같지만 실제 벤치마크를 참조 해 보면 큰 성능 차이는 없는 것으로 확인 되었다
Order by 정렬
- 크게 모든 데이터를 소트 버퍼에 읽어온 후 정렬을 수행할지와 PK를 일단 소트버퍼에서 정렬하고 반환할지 두 가지가 있다
- 최신 버전에서는 전자의 방법을 많이 사용 한다고 한다
- 인덱스는 기본적으로 정렬된 상태이므로 엔진 내부에서 별도의 정렬을 수행하진 않는다.
- 그래서 order by를 명시적으로 수행해도 mysql이 정렬을 별도로 수행하지 않으므로 느려질 것 같다고 빼지말고 그냥 쓰도록 하자
- 조인시 드라이빙 테이블 정렬은 해당 테이블만 파일소트로 정렬한 후 드리븐 테이블과 조인을 수랭한다
- 임시 테이블을 사용한 정렬은 가장 느리다 왜냐면 조인 결과를 임시테이블에 저장하고 임시 테이블을 또 정렬해줘야하니까
Group by 정렬
- group by 조건은 인덱스를 사용해 처리 할 수 없다
- 이 조건은 크게 인덱스를 타는 경우와 그렇지 않은 경우로 나뉜다
- 인덱스를 타는 경우 차례대로 읽는 인덱스 스캔과 건너뛰는 루스 인덱스로 나뉜다
- 인덱스를 못타면 임시 테이블을 쓴다
Distinct
- select distinct(name), age from table 쿼리는 name과 age가 유니크한 레코드를 조회하는 쿼리임
최적화 기법들
- 블록 네스티드 루프 조인은 기존 네스티드 루프에서 조인을 위한 별도의 버퍼의 존재 유무로 결정된다
- 해시 조인은 첫 번째 레코드를 찾는데 오래 걸리지만 마지막 레코드를 찾는 시간은 빠르다 그렇기에 일반적인 웹 서비스에서 적절하지 않으므로 네스티드 루프 조인을 못 쓰는 경우의 차선책으로 고려해볼만 하다
통계 정보
- 히스토그램을 통해 테이블의 대략적인 레코드 분포를 확인할 수 있음
- 이 히스토그램을 통해 옵티마이저는 최적의 쿼리로 개선해준다
- 그러나 현재까지 옵티마이저는 주로 인덱스를 통해 실행 계획을 고르는데, 이러한 인덱스를 통해 B-Tree를 샘플링하는 기법을 인덱스 다이브라 부른다
- 당연히 이 인덱스 다이브는 히스토그램보다 비용이 크기 때문에 추후에는 이러한 최적화도 히스토그램을 사용하지 않을까라고 저자는 추측했다
tmxkqotnl
DaehunGwak
진도
9.2 기본 데이터 처리 9.3 고급 최적화 10.1 통계 정보
일정