10.2.1 Optimizing SELECT Statements

10.2.1 Optimizing SELECT Statements

10.2.1.1 WHERE Clause Optimization
10.2.1.2 Range Optimization
10.2.1.3 Index Merge Optimization
10.2.1.4 Hash Join Optimization
10.2.1.5 Engine Condition Pushdown Optimization
10.2.1.6 Index Condition Pushdown Optimization
10.2.1.7 Nested-Loop Join Algorithms
10.2.1.8 Nested Join Optimization
10.2.1.9 Outer Join Optimization
10.2.1.10 Outer Join Simplification
10.2.1.11 Multi-Range Read Optimization
10.2.1.12 Block Nested-Loop and Batched Key Access Joins
10.2.1.13 Condition Filtering
10.2.1.14 Constant-Folding Optimization
10.2.1.15 IS NULL Optimization
10.2.1.16 ORDER BY Optimization
10.2.1.17 GROUP BY Optimization
10.2.1.18 DISTINCT Optimization
10.2.1.19 LIMIT Query Optimization
10.2.1.20 Function Call Optimization
10.2.1.21 Window Function Optimization
10.2.1.22 Row Constructor Expression Optimization
10.2.1.23 Avoiding Full Table Scans

SELECT statement 형태의 쿼리는 데이터베이스에서 모든 조회 연산을 수행합니다. 이러한 statement를 튜닝하는 것은, 동적 웹 페이지에 대해 서브초 응답 시간을 달성하거나, 대규모 야간 리포트를 생성하는 데 걸리는 시간을 수시간 단축하기 위해, 최우선 과제입니다.

SELECT statement 외에도, 쿼리에 대한 튜닝 기법은 다음과 같은 구문에도 적용됩니다: CREATE TABLE...AS SELECT, INSERT INTO...SELECT, 그리고 DELETE statement의 WHERE 절. 이러한 statement는 쓰기 연산을 읽기 지향적인 쿼리 연산과 결합하기 때문에 추가적인 성능 고려 사항을 가집니다.

NDB Cluster는, 조건을 충족하는 조인 전체를 NDB Cluster 데이터 노드로 보내어, 그 사이에 분산시키고 병렬로 실행할 수 있도록 하는 조인 푸시다운 최적화를 지원합니다. 이 최적화에 대한 자세한 정보는 Conditions for NDB pushdown joins를 참고하십시오.

쿼리를 최적화할 때의 주요 고려 사항은 다음과 같습니다:

• 느린 SELECT ... WHERE 쿼리를 더 빠르게 만들기 위해 첫 번째로 확인할 것은 인덱스를 추가할 수 있는지 여부입니다. WHERE 절에서 사용되는 컬럼에 인덱스를 설정하여, 평가, 필터링, 그리고 최종 결과 조회를 가속하십시오. 디스크 공간 낭비를 방지하기 위해, 애플리케이션에서 사용하는 많은 관련 쿼리를 가속하는 소수의 인덱스 집합을 구성하십시오.

• 인덱스는 특히 조인 및 외래 키와 같은 기능을 사용하여 서로 다른 테이블을 참조하는 쿼리에서 중요합니다. EXPLAIN statement를 사용하여 어떤 인덱스가 SELECT에 사용되는지 확인할 수 있습니다. Section 10.3.1, “How MySQL Uses Indexes” 및 Section 10.8.1, “Optimizing Queries with EXPLAIN”을 참고하십시오.

• 과도한 시간을 소모하는 함수 호출과 같은, 쿼리의 일부를 분리하고 튜닝하십시오. 쿼리 구조에 따라, 함수는 결과 집합의 각 로우마다, 또는 심지어 테이블의 각 로우마다 한 번씩 호출될 수 있어, 비효율성이 크게 증폭될 수 있습니다.

• 특히 큰 테이블에 대해, 쿼리에서 풀 테이블 스캔의 수를 최소화하십시오.

• 옵티마이저가 효율적인 실행 계획을 구성하는 데 필요한 정보를 가질 수 있도록, ANALYZE TABLE statement를 주기적으로 사용하여 테이블 통계를 최신 상태로 유지하십시오.

• 각 테이블에 대해 스토리지 엔진별로 제공되는 튜닝 기법, 인덱싱 기법, 그리고 설정 파라미터를 숙지하십시오. InnoDB와 MyISAM 모두 쿼리에서 높은 성능을 활성화하고 유지하기 위한 지침 모음을 가지고 있습니다. 자세한 내용은 Section 10.5.6, “Optimizing InnoDB Queries” 및 Section 10.6.1, “Optimizing MyISAM Queries”를 참고하십시오.

• InnoDB 테이블에 대해, Section 10.5.3, “Optimizing InnoDB Read-Only Transactions”에 설명된 기법을 사용하여 단일 쿼리 트랜잭션을 최적화할 수 있습니다.

• 특히 옵티마이저가 동일한 변환을 자동으로 수행하는 경우, 쿼리를 이해하기 어렵게 만드는 방식으로 변환하는 것을 피하십시오.

• 성능 문제가 기본 가이드라인 중 하나로 쉽게 해결되지 않는다면, EXPLAIN 플랜을 검토하고 인덱스, WHERE 절, 조인 절 등을 조정하여 특정 쿼리의 내부 세부 정보를 조사하십시오. (특정 수준의 전문성에 도달하면, EXPLAIN 플랜을 읽는 것이 모든 쿼리에 대한 첫 단계가 될 수 있습니다.)

• MySQL이 캐싱에 사용하는 메모리 영역의 크기와 속성을 조정하십시오. InnoDB 버퍼 풀, MyISAM 키 캐시, 그리고 MySQL 쿼리 캐시를 효율적으로 사용하면, 같은 쿼리가 두 번째 이후 실행될 때 결과가 메모리에서 조회되므로 더 빠르게 실행됩니다.

• 캐시 메모리 영역을 사용하여 빠르게 실행되는 쿼리라 하더라도, 필요한 캐시 메모리 양을 줄여 애플리케이션의 확장성을 향상시키기 위해 추가로 최적화할 수 있습니다. 확장성이란, 성능이 크게 저하되지 않으면서 애플리케이션이 더 많은 동시 사용자, 더 큰 요청 등을 처리할 수 있는 능력을 의미합니다.

• 다른 세션이 동일한 시점에 테이블에 접근함으로써, 쿼리의 속도가 영향을 받을 수 있는 잠금 이슈를 처리하십시오.