책너두 6기 37일차

백은빈, 이성욱의 Real MySQL 8.0 1권 p.393 ~ p.411

내용정리

10 실행계획

많은 데이터를 안전하게 저장 및 관리하고 사용자가 원하는 데이터를 빠르게 조회하는 것이 중요하다. 이를 위해, 옵티마이저가 사용자의 쿼리를 최적으로 처리할 수 있게 하는 쿼리의 실행 계획을 수립할 수 있어야 한다. 실행 계획을 읽고 이해하려면 서버가 데이터를 처리하는 로직을 이해해야 한다.

10.1 통계 정보

테이블과 인덱스에 대한 개괄적인 정보와 인덱스되지 않은 칼럼들에 대해서 데이터 분포도를 수집해서 저장된 히스토그램 정보로 실행 계획을 수립한다.

10.1.1 테이블 및 인덱스 통계 정보

비용 기반 최적화에서 가장 중요한 것은 통계 정보다. 정확하지 않으면 잘못된 방향으로 쿼리를 실행한다.

10.1.1.1 MySQL 서버의 통계 정보

테이블에 대한 통계 정보를 영구적으로 관리할 수 있다.

10.1.2 히스토그램

히스토그램 정보는 칼럼의 데이터 분포도를 참조할 수 있다. 칼럼 단위로 관리되는데, 자동읗로 수집되지는 않는다.

Singleton(싱글톤 히스토그램) : 칼럼값 개별로 레코드 건수를 관리하는 히스토그램
Equi-Height(높이 균형 히스토그램) : 칼럼값의 범위를 균등한 개수로 구분해서 관리하는 히스토그램

히스토그램은 버킷(Bucket) 단위로 구분되어 레코드 건수나 칼럼값의 범위가 관리되는데, 싱글톤은 칼럼이 가지는 값별로 버킷이 할당되며 높이 균형에서는 개수가 균등한 칼럼값의 범위별로 하나의 버킷이 할당된다.

히스토그램은 삭제할 수 있지만 테이블의 데이터를 참조하는 것이 아니라 딕셔너리의 내용만 삭제하기 때문에 즉시 삭제된다. 하지만 쿼리의 실행 계획은 달라질 수 있다.

10.1.2.2 히스토그램의 용도

실제 응용 프로그램의 데이터는 항상 균등한 분포도를 가지지 않는다. 히스토그램은 이러한 부분을 보완해준다. 각 범위 별로 레코드의 건수와 유니크한 값의 개수 정보를 가지기 떄문이다.

10.1.2.3 히스토그램과 인덱스

둘은 완전히 다른 객체지만, 부족한 통계 정보를 수집하기 위해 사용된다는 공통점은 있다.

인덱스 다이브(Index Dive):조건절에 일치하는 레코드 건수를 예측하기 위해 옵티마이저가 실제 인덱스의 B-Tree를 샘플링해서 살펴보는 것

10.1.3 코스트 모델(Cost Model)

쿼리를 처리하려면 다양한 작업이 필요하다.

디스크로부터 페이지 읽기
메모리로부터 데이터 페이지 읽기
인덱스 키 비교
레코드 평가
메모리 임시 테이블 작업
디스크 임시 테이블 작업

이러한 작업들이 얼마나 필요한지 예측하여 실행 계획을 찾는다. 이 때 단위 작업들의 비용을 코스트 모델이라 한다. 이 비용은 관리자가 조정할 수 있다.