MySQL의 전반적인 아키텍처에 대한 간략한 논의

머리말

또 새로운 한 주가 시작되었습니다. 모두들 행복한 월요일입니다.

직장을 바꾸고 집을 구하는 일로 인해 일련의 일들이 밀려서 최근 한 달 넘게 업데이트를 중단했습니다. 이제 모든 것이 해결되었으므로 안심하고 코딩할 수 있습니다.

자, 더 이상 고민하지 말고 새로운 여행을 시작해 보세요. 최근 "MySQL Technology Insider - InnoDB Storage Engine"이라는 책을 읽고 있어서 그냥 기록해 보고 싶습니다.

전체 아키텍처 다이어그램

전체적인 이해를 위해 먼저 MySQL의 아키텍처 다이어그램을 살펴보겠습니다. MySQL은 주로 네트워크 연결 계층, 서비스 계층, 스토리지 엔진 계층 및 물리 계층의 네 가지 아키텍처 계층으로 나뉩니다. 우리가 일반적으로 작성하는 SQL문과 SQL문의 최적화는 모두 서비스 계층에서 이루어지므로 실제로는 SQL문이 예상한 결과에 따라 실행될 수 있습니다.

각 부분 소개

네트워크 연결 계층

주로 연결 관리, 인증 인증, 보안 등을 담당합니다. 각 클라이언트 연결은 서버의 스레드에 해당합니다. 각 연결에 대한 스레드 생성 및 삭제를 방지하려면 서버에서 스레드 풀을 유지 관리하세요. 클라이언트가 MySQL 서버에 연결되면 서버가 이를 인증합니다. 사용자 이름과 비밀번호를 통해 인증할 수도 있고, SSL 인증서를 통해 인증할 수도 있습니다. 로그인 인증 후 서버는 클라이언트가 특정 쿼리를 실행할 권한이 있는지 여부도 확인합니다. 이 계층은 MySQL만의 고유한 기술이 아닙니다.

서비스 레이어

이 레이어는 쿼리 캐시, 파서, 파싱 트리, 전처리기, 쿼리 최적화 프로그램을 포함하는 MySQL의 핵심입니다.

• Query Cache

정식 쿼리 이전에 서버는 쿼리 캐시를 확인하여 해당 쿼리를 찾을 수 있으면 쿼리 구문 분석, 최적화, 실행 등을 수행할 필요가 없습니다. 캐시에 결과 세트를 직접 반환합니다.

• 파서 및 전처리기

MySQL의 파서는 쿼리 문을 기반으로 구문 분석 트리를 구성합니다. 이는 주로 SQL 키워드가 올바른지와 같은 문법 규칙을 기반으로 문이 올바른지 확인하는 데 사용됩니다. 키워드의 순서가 올바른가요?

전처리기는 주로 테이블 이름과 필드 이름이 올바른지 등과 같은 추가 확인을 위한 것입니다.

• Query Optimizer

쿼리 최적화 프로그램은 구문 분석 트리를 쿼리 계획으로 변환하며, 쿼리는 다양한 방법으로 실행될 수 있으며 궁극적으로 동일한 결과를 반환합니다. 실행 계획

• 실행 계획

분석 및 최적화 단계가 완료된 후 MySQL은 스토리지 엔진 계층에서 제공하는 해당 인터페이스를 호출하여 해당 실행 계획에 따른 결과를 얻습니다.

스토리지 엔진 계층

은 MySQL 데이터의 저장 및 검색을 담당하며 다양한 엔진 간의 차이점을 보호하기 위해 일련의 인터페이스를 제공합니다.

注意：存储引擎是针对表的，而不是针对库。也就是说同一个库里面的不同表可以拥有不同的存储引擎。

MyISAM과 InnoDB라는 두 가지 일반적인 스토리지 엔진이 있습니다.

먼저 스토리지 엔진 MyISAM을 사용하여 test1 테이블을 생성합니다.

create table test1( a INTEGER, b varchar(10) )ENGINE=MyISAM;

MySQL의 관련 디렉터리로 이동하여 실제 저장된 내용을 확인하고 해당 내용이 세 개의 파일에 해당하는지 확인할 수 있습니다.

두 번째로 스토리지 엔진이 InnoDB인 test2 테이블을 생성합니다.

create table test2( a INTEGER, b varchar(10) )ENGINE=INNODB;

실제 저장된 내용을 살펴보고 이 파일과 일치하는지 알아봅시다.

그러면 데이터 파일과 인덱스 파일이 어디에 저장되어 있는지 궁금합니다. 지금은 여기서 질문을 남기고 다음 장인 "문서"에서 이에 대해 이야기하겠습니다.

물리적 계층

은 데이터를 하드 드라이브에 저장합니다.

전체 프로세스

SQL 문을 보내는데, MySQL의 전체 프로세스는 어떻게 되나요?

• 사용자는 먼저 Navicat과 같은 클라이언트를 통해 서버와 연결을 설정합니다. 인증을 위해 사용자 이름과 비밀번호가 필요하거나 SSL 인증서를 사용하여 인증할 수 있습니다.

• 로그인에 성공하면 MySQL은 해당 권한을 기반으로 역할에 일부 테이블에 대한 권한이 있는지 여부를 결정합니다.

• 해당 권한이 있는 경우 사용자가 쿼리 선택 문을 보낼 때 MySQL은 먼저 캐시를 쿼리합니다. 이 명령문에 대한 캐시가 이미 있으면 직접 반환하며 다음 프로세스가 실행됩니다. . 업데이트, 신규삽입, 삭제인 경우에는 캐시를 조회하지 않고 바로 다음 과정을 수행한다.

• MySQL은 SQL 문을 트리로 구문 분석한 다음 키워드가 올바른지, 키워드 순서가 올바른지, 테이블 이름이 올바른지, 필드가 올바른지 등을 확인합니다. 인증에 실패하면 바로 오류가 반환됩니다. 인증에 성공했다면 바로 다음 과정을 진행하세요.

• MySQL은 여러 SQL이 동일한 의미를 표현할 수 있지만 소요되는 시간은 크게 다를 수 있으므로 구문 분석 트리에서 쿼리 최적화를 수행합니다. 따라서 MySQL은 테이블의 스토리지 엔진에 대한 최적의 명령문 실행을 찾아 해당 실행 계획을 생성합니다.

• 위에서 생성된 실행 계획을 사용하여 스토리지 엔진 레이어 인터페이스를 호출합니다. 이것이 우리가 일반적으로 사용하는 설명으로, 인덱스의 색인 여부, 소요 시간 및 기타 정보를 확인하는 데 사용할 수 있습니다.

• 다른 스토리지 엔진은 해당 물리적 ​​스토리지 위치로 이동하여 해당 데이터를 찾아 패키지하고 결과를 반환합니다.

• 결과 세트를 얻었고 이것이 select 문인 경우 MySQL은 다음에 동일한 작업을 수행하여 발생하는 리소스 소비를 피하기 위해 결과를 캐시에 저장하는 동시에 결과를 클라이언트에 반환합니다. 이 시점에서 SQL 문의 실행이 완료됩니다.

더 많은 MySQL 관련 기술 기사를 보려면 MySQL Tutorial 칼럼을 방문하여 알아보세요!

위 내용은 MySQL의 전반적인 아키텍처에 대한 간략한 논의의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!