8.8.5.1 쿼리 계획 평가의 제어
쿼리 최적화 작업은 SQL 쿼리를 실행하기 위해 최적의 플랜을 찾을 수 있습니다. "좋은"계획과 "나쁜"계획의 성능 차이는 현격 한 차이 (즉, 몇 초에 몇 시간이나 며칠까지) 될 가능성이 있기 때문에 MySQL의 최적화를 포함한 대부분의 쿼리 최적화 어느 정도 가능한 모든 쿼리 평가 계획 중에서 최적의 계획을 철저하게 찾습니다. 결합 쿼리에 대해 MySQL 최적화에 의해 조사 될 계획의 수는 쿼리에서 참조되는 테이블 수와 함께 기하 급수적으로 증가합니다. 몇몇 테이블 (일반적으로 7 ~ 10 미만)의 경우 이것은 문제가되지 않습니다. 그러나 큰 쿼리가 전송 된 경우 쿼리 최적화에 소요되는 시간이 서버 성능의 주요 병목 현상하는 경향이 있습니다.
쿼리 최적화 더 유연한 방법으로 사용자는 최적화 프로그램이 최적의 쿼리 평가 계획을 얼마나 철저하게 검색을 제어 할 수 있습니다. 일반적인 생각은 최적화에 의해 조사 된 계획이 적을수록 쿼리 컴파일에 걸리는 시간도 줄어들 것입니다. 한편, 최적화는 어떤 계획을 생략하기 위해 최적의 플랜을 놓칠 가능성도 있습니다.
평가 계획의 수에 대한 최적화 작업을 2 개의 시스템 변수를 사용하여 제어 할 수 있습니다.
optimizer_prune_level변수는 최적화 테이블마다 액세스되는 행 수의 견적에 따라 특정 계획을 건너 뛰도록 지시합니다. 경험상 이러한 종류의 "학습에 의한 추측"최적의 플랜을 거의 놓치지 않고 쿼리 컴파일 시간을 획기적으로 단축 할 수 있습니다. 기본적으로이 옵션이 선택optimizer_prune_level=1인 것은이 때문입니다. 그러나 최적화가 더 적합한 쿼리 계획을 묵인했다고 생각한다면, 쿼리 컴파일에 상당한 시간이 걸릴 위험을 수반하지만이 옵션을 해제 (optimizer_prune_level=0) 할 수 있습니다. 이 경험칙을 사용하여 최적화는 아직 기하 급수적 인 숫자의 플랜을 검색합니다.optimizer_search_depth변수는 최적화가 더 확장해야할지 여부를 평가하기 위해 불완전한 각 계획의 "미래"를 어느 정도 간파을 전합니다.optimizer_search_depth값이 작을수록 쿼리 컴파일 시간이 현격하게 줄어들 수 있습니다. 예를 들어, 12, 13 또는 그 이상의 테이블의 쿼리는optimizer_search_depth가 쿼리의 테이블 수에 가까운 경우 컴파일에 몇 시간 또는 며칠도 쉽게 필요할 수 있습니다. 동시에 3 4와 동일한optimizer_search_depth로 컴파일 된 경우 최적화 프로그램은 같은 쿼리에서 1 분 이내에 컴파일 할 수 있습니다.optimizer_search_depth적절한 값을 알 수없는 경우이 변수를 0으로 설정하여 최적화에 자동으로 값을 결정 할 수 있습니다.