mysql 실행 프로세스 분석

MySQL은 두 부분으로 나눌 수 있습니다: 서버 계층과 스토리지 엔진 계층

서버 계층에는 MySQL의 핵심 서비스 기능 대부분을 다루는 커넥터, 쿼리 캐시, 분석기, 최적화 프로그램, 실행 프로그램 등이 포함됩니다. 모든 기본 제공 기능뿐만 아니라 저장 프로시저, 트리거, 뷰 등과 같은 모든 교차 스토리지 엔진 기능도 이 계층에서 구현됩니다. 스토리지 엔진 계층은 데이터 저장 및 검색을 담당합니다. 아키텍처 모델은 플러그인이며 InnoDB, MyISAM 및 Memory와 같은 여러 스토리지 엔진을 지원합니다. 현재 가장 일반적으로 사용되는 스토리지 엔진은 InnoDB입니다

(무료 학습 동영상 튜토리얼 추천:

mysql 동영상 튜토리얼

)SQL 실행 프로세스를 살펴보겠습니다

Connector

첫 번째 단계에서 먼저 connect to 이 데이터베이스에서는 지금 커넥터가 사용자를 수신합니다. 커넥터는 클라이언트와의 연결 설정, 권한 획득, 연결 유지 및 관리를 담당합니다.

연결이 완료된 후 후속 작업이 없으면 연결이 유휴 상태로 유지되는 것을 확인할 수 있습니다. show processlist command

Client 너무 오랫동안 움직임이 없으면 커넥터가 자동으로 연결을 끊습니다. 이 시간은 wait_timeout 매개변수에 의해 제어되며 기본값은 8시간입니다

연결 설정 과정은 일반적으로 더 복잡하므로 사용 중에는 연결 설정 작업을 최소화해야 합니다. 즉, 긴 연결을 사용해 보세요

하지만 모두 긴 연결을 사용합니다. 연결한 후 MySQL이 차지하는 메모리가 매우 빠르게 증가하는 경우가 있습니다. 이는 MySQL이 실행 중에 임시로 사용하는 메모리를 연결 개체에서 관리하기 때문입니다. 이러한 리소스는 연결이 끊어진 경우에만 해제됩니다. 이 문제를 해결하는 방법은 다음 두 가지 옵션입니다.

1. 정기적으로 긴 연결을 끊습니다. 일정 기간 사용 후 또는 프로그램에서 메모리를 차지하는 큰 쿼리가 실행된 것으로 판단한 후 연결이 끊어진 후 쿼리가 필요했다가 다시 연결됩니다.

2. MySQL 5.7 이상을 사용하는 경우 상대적으로 큰 작업을 실행할 때마다 mysql_reset_connection을 실행하여 연결 리소스를 다시 초기화할 수 있습니다. 이 과정에서는 재접속 및 권한 확인이 필요하지 않으나, 접속이 방금 생성되었을 때의 상태로 복원됩니다

쿼리 캐시

접속이 완료된 후 select 문을 실행할 수 있습니다. 실행 로직은 두 번째 단계인 쿼리 캐시로 넘어갑니다. MySQL은 쿼리 요청을 받은 후 먼저 쿼리 캐시로 이동하여 이전에 이 명령문이 실행되었는지 확인합니다. 이전에 실행된 명령문과 그 결과는 키-값 쌍의 형태로 메모리에 직접 캐시될 수 있습니다. 키는 쿼리 문이고 값은 쿼리 결과입니다. 쿼리가 이 캐시에서 키를 직접 찾을 수 있으면 값이 클라이언트에 직접 반환됩니다. 쿼리 캐시에 문이 없으면 후속 실행 단계가 계속됩니다. 실행이 완료된 후 실행 결과는 쿼리 캐시에 저장됩니다. 쿼리가 캐시에 도달하면 후속 복잡한 작업을 수행하지 않고도 MySQL이 직접 결과를 반환할 수 있다는 것을 알 수 있습니다. 이 효율성은 매우 높습니다

그러나 대부분의 경우 쿼리 캐시를 사용하지 않는 이유는 무엇입니까? 이익보다 단점이 더 크다.

쿼리 캐시가 매우 자주 실패합니다. 테이블이 업데이트되는 한 이 테이블의 모든 쿼리 캐시는 지워집니다. 따라서 결과를 저장하는 데 어려움을 겪었고 사용하기도 전에 업데이트로 인해 결과가 지워졌을 가능성이 있습니다. 업데이트 압력이 심한 데이터베이스의 경우 쿼리 캐시 적중률이 매우 낮습니다. 귀하의 비즈니스에 장기간 업데이트되는 정적 테이블이 있는 경우를 제외하고

query_cache_type 매개변수를 DEMAND로 설정하면 기본 SQL 문에 쿼리 캐시가 사용되지 않습니다.

MySQL 버전 8.0은 쿼리를 직접 캐시합니다. 전체 함수가 삭제되었습니다. 즉, 8.0부터 이 함수가 완전히 사라졌다는 의미입니다.

Analyzer

쿼리 캐시에 적중되지 않으면 실제 명령문 실행이 시작됩니다. 우선 MySQL은 사용자가 수행하려는 작업이 무엇인지 알아야 하므로 분석기는 먼저 "어휘 분석"을 수행합니다. 입력한 내용은 여러 문자열과 공백으로 구성된 SQL 문입니다. MySQL은 해당 문자열이 무엇인지, 무엇을 나타내는지 식별해야 합니다. 이러한 식별을 완료한 후 "구문 분석"을 수행해야 합니다. 어휘 분석 결과에 따라 구문 분석기는 입력한 SQL 문이 문법 규칙에 따라 MySQL 구문을 만족하는지 확인합니다

Optimizer

분석기를 통과한 후 MySQL은 사용자가 원하는 작업을 알게 됩니다. 실행이 시작되기 전에 최적화 프로그램에서 처리해야 합니다.

옵티마이저는 테이블에 여러 인덱스가 있거나 명령문에 여러 테이블 연결(조인)이 있는 경우 사용할 인덱스를 결정하고 각 테이블의 연결 순서를 결정합니다.

옵티마이저 단계가 완료된 후 이 명령문은 실행 계획이 결정되면 Executor 단계에 들어갑니다

executor

실행을 시작할 때 먼저 이 테이블 T에 대해 쿼리를 실행할 권한이 있는지 확인해야 합니다. 그렇지 않은 경우 권한 없음 오류가 반환됩니다.

권한이 있으면 열기 테이블 실행을 계속합니다. 테이블이 열리면 Executor는 엔진에서 제공하는 인터페이스를 사용하여 테이블의 엔진 정의에 따라 실행합니다.

이 시점에서 서버 계층은 특정 엔진 계층 로직의 실행을 완료했습니다. . 다음 글에서 다루도록 하겠습니다. 분석

위 내용은 mysql 실행 프로세스 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!