고성능 MySQL, 제 4판

8장. 쿼리 성능 최적화

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이전 장에서는 고성능을 위해 필요한 스키마 최적화와 인덱싱에 대해 설명했습니다. 하지만 이것만으로는 충분하지 않습니다. 쿼리도 잘 설계해야 합니다. 쿼리가 나쁘면 아무리 잘 설계된 스키마와 인덱스라도 성능이 좋지 않습니다.

쿼리 최적화, 인덱스 최적화, 스키마 최적화는 함께 진행됩니다. MySQL에서 쿼리를 작성하는 경험이 쌓이면 효율적인 쿼리를 지원하기 위해 테이블과 인덱스를 설계하는 방법을 배우게 됩니다. 마찬가지로, 최적의 스키마 설계에 대해 배운 내용은 작성하는 쿼리의 종류에 영향을 미칩니다. 이 과정은 시간이 걸리므로 자세한 내용을 배우면서 이 세 장을 다시 참조하는 것이 좋습니다.

이 장에서는 일반적인 쿼리 설계 고려 사항, 즉 쿼리 성능이 좋지 않을 때 가장 먼저 고려해야 할 사항으로 시작합니다. 그런 다음 쿼리 최적화와 서버 내부를 훨씬 더 깊이 파헤칩니다. MySQL이 특정 쿼리를 실행하는 방법을 알아보고 쿼리 실행 계획을 변경하는 방법을 배웁니다. 마지막으로 MySQL이 쿼리를 제대로 최적화하지 못하는 몇 가지 부분을 살펴보고 MySQL이 쿼리를 더 효율적으로 실행하는 데 도움이 되는 쿼리 최적화 패턴을 살펴봅니다.

우리의 목표는 MySQL이 실제로 쿼리를 실행하는 방식을 깊이 있게 이해하여 무엇이 효율적이고 비효율적인지 추론하고, MySQL의 강점을 활용하고 약점을 피할 수 있도록 돕는 것입니다.

쿼리 속도가 느린 이유는 무엇인가요?

빠른 쿼리를 작성하기 전에 가장 중요한 것은 응답 시간이라는 점을 기억하세요. 쿼리는 작업이지만 하위 작업으로 구성되며 이러한 하위 작업은 시간을 소비합니다. 쿼리를 최적화하려면 하위 작업을 제거하거나, 실행 횟수를 줄이거나, 더 빨리 실행되도록 하여 쿼리의 하위 작업을 최적화해야 합니다.

일반적으로 쿼리의 수명은 쿼리가 클라이언트에서 서버로 이동하여 구문 분석, 계획, 실행된 후 다시 클라이언트로 돌아오는 시퀀스 다이어그램을 통해 정신적으로 쿼리를 따라가는 것으로 생각할 수 있습니다. 실행은 쿼리의 수명 주기에서 가장 중요한 단계 중 하나입니다. 여기에는 행을 검색하기 위해 스토리지 엔진에 대한 많은 호출과 그룹화 및 정렬과 같은 검색 후 작업이 포함됩니다.

이러한 모든 작업을 수행하는 동안 쿼리는 네트워크, CPU, 통계, 계획, 잠금(뮤텍스 대기), 특히 행을 검색하기 위한 스토리지 엔진 호출과 같은 작업에서 시간을 소비합니다. 이러한 호출은 메모리 작업, CPU 작업, 특히 데이터가 메모리에 없는 경우 I/O 작업에서 시간을 소모합니다. 스토리지 엔진에 따라 많은 컨텍스트 전환 및/또는 시스템 호출도 포함될 수 있습니다.

모든 경우에 작업이 불필요하게 수행되거나, 너무 많이 수행되거나, 너무 느려서 과도한 시간이 소모될 수 있습니다. 최적화의 목표는 작업을 제거하거나 줄이거나 더 빠르게 만들어 이러한 상황을 방지하는 것입니다. ...