【MySQL】MySQL 논리 구조

MySQL의 다양한 구성요소가 어떻게 함께 작동하는지를 염두에 두고 아키텍처 다이어그램을 구축할 수 있다면 MySQL 서버를 깊이 이해하는 데 도움이 될 것입니다.

최상위 서비스는 MySQL에만 고유한 것이 아니며 대부분의 네트워크 기반 클라이언트/서버 도구는 비슷한 아키텍처를 가지고 있습니다. 접속처리, 권한인증, 보안 등

두 번째 계층 아키텍처는 MySQL에서 더욱 흥미로운 부분입니다. 쿼리 구문 분석, 분석, 최적화, 캐싱 및 모든 내장 기능(예: 날짜, 시간, 수학 및 암호화 기능)을 포함하여 MySQL의 핵심 서비스 기능 대부분이 이 계층에 있습니다. 계층 구현: 저장 프로시저, 트리거, 뷰 등

세 번째 레이어에는 스토리지 엔진이 포함되어 있습니다. 스토리지 엔진은 MySQL에서 데이터의 저장 및 검색을 담당합니다. GNU/Linux의 다양한 파일 시스템과 마찬가지로 각 스토리지 엔진에는 장점과 단점이 있습니다. 서버는 API를 통해 스토리지 엔진과 통신합니다. 이러한 인터페이스는 서로 다른 스토리지 엔진 간의 차이점을 보호하여 이러한 차이점을 상위 계층 쿼리 프로세스에 투명하게 만듭니다. 스토리지 엔진 API에는 "트랜잭션 시작" 또는 "기본 키를 기반으로 한 레코드 행 추출"과 같은 작업을 수행하기 위한 12개 이상의 하위 수준 기능이 포함되어 있습니다. 그러나 스토리지 엔진은 SQL을 구문 분석하지 않습니다(참고: InnoDB는 예외입니다. MySQL 서버 자체는 이 기능을 구현하지 않기 때문에 외래 키 정의를 구문 분석합니다). 서로 다른 스토리지 엔진은 서로 통신하지 않지만 단순히 응답합니다. 상위 계층 서버 요청에.

연결 관리 및 보안

각 클라이언트 연결에는 서버 프로세스에 스레드가 있습니다. 이 연결에 대한 쿼리는 이 별도의 스레드에서만 실행되며, 실행 중인 스레드에서만 실행됩니다. 특정 CPU 코어 또는 CPU. 서버는 스레드 캐싱을 담당하므로 새 연결마다 스레드를 생성하거나 삭제할 필요가 없습니다. (참고: MySQL 5.5 이상에서는 스레드 풀 플러그인을 지원하는 API를 제공합니다. 이 플러그인은 풀에서 적은 수의 스레드를 사용하여 많은 수의 연결을 제공할 수 있습니다.)

클라이언트(애플리케이션)가 MySQL 서버에 연결되면 서버에서 이를 인증해야 합니다. 인증은 사용자 이름, 원래 호스트 정보 및 비밀번호를 기반으로 합니다. 보안 소켓(SSL) 연결을 사용하는 경우 X.509 인증서 인증도 사용할 수 있습니다. 클라이언트가 성공적으로 연결되면 서버는 클라이언트가 특정 쿼리에 대한 권한을 가지고 있는지 계속해서 확인합니다(예: 클라이언트가 세계 데이터베이스의 국가 테이블에서 SELECT 문을 실행할 수 있는지 여부).

최적화 및 실행

MySQL은 쿼리를 구문 분석하고 내부 데이터 구조(파싱 트리)를 생성한 다음 쿼리 재작성, 쿼리 읽기 순서 결정 등 다양한 최적화를 수행합니다. 테이블, 적절한 인덱스 선택 등 사용자는 특별한 키워드 힌트를 통해 최적화 프로그램의 의사 결정 프로세스에 영향을 미칠 수 있습니다. 또한 최적화 프로세스의 다양한 요소에 대한 설명을 최적화 프로그램에 요청하여 서버가 어떻게 최적화 결정을 내리는지 사용자가 알 수 있도록 하고, 사용자가 쿼리 및 스키마를 재구성하고 관련 구성을 수정하여 애플리케이션을 효율적으로 만들 수 있도록 참조 벤치마크를 제공할 수 있습니다. 가능한 한 실행하십시오.

옵티마이저는 어떤 스토리지 엔진이 사용되는지 상관하지 않지만 스토리지 엔진은 쿼리 최적화에 영향을 미칩니다. 옵티마이저는 스토리지 엔진에 특정 작업의 용량이나 비용 정보, 테이블 데이터의 통계 정보 등을 요청합니다. 예를 들어, 특정 스토리지 엔진의 특정 인덱스는 특정 쿼리에 대해 최적화될 수 있습니다.

SELECT 문의 경우 서버는 쿼리를 파싱하기 전에 먼저 쿼리 캐시(Query Cache)를 확인하고, 해당 쿼리가 있으면 서버가 쿼리 전체 과정을 수행할 필요가 없습니다. 대신 쿼리 캐시에 설정된 결과가 직접 반환됩니다.

MySQL의 다양한 구성 요소가 어떻게 함께 작동하는지 마음속에 아키텍처 다이어그램을 구축할 수 있다면 MySQL 서버를 깊이 이해하는 데 도움이 될 것입니다.

최상위 서비스는 MySQL에만 고유한 것이 아니며 대부분의 네트워크 기반 클라이언트/서버 도구는 유사한 아키텍처를 가지고 있습니다. 접속처리, 권한인증, 보안 등

두 번째 계층 아키텍처는 MySQL에서 더 흥미로운 부분입니다. 쿼리 구문 분석, 분석, 최적화, 캐싱 및 모든 내장 기능(예: 날짜, 시간, 수학 및 암호화 기능)을 포함하여 MySQL의 핵심 서비스 기능 대부분이 이 계층에 있습니다. 계층 구현: 저장 프로시저, 트리거, 뷰 등

세 번째 레이어에는 스토리지 엔진이 포함되어 있습니다. 스토리지 엔진은 MySQL에서 데이터의 저장 및 검색을 담당합니다. GNU/Linux의 다양한 파일 시스템과 마찬가지로 각 스토리지 엔진에는 장점과 단점이 있습니다. 서버는 API를 통해 스토리지 엔진과 통신합니다. 이러한 인터페이스는 서로 다른 스토리지 엔진 간의 차이점을 보호하여 이러한 차이점을 상위 계층 쿼리 프로세스에 투명하게 만듭니다. 스토리지 엔진 API에는 "트랜잭션 시작" 또는 "기본 키를 기반으로 한 레코드 행 추출"과 같은 작업을 수행하기 위한 12개 이상의 하위 수준 함수가 포함되어 있습니다. 그러나 스토리지 엔진은 SQL을 구문 분석하지 않습니다(참고: InnoDB는 예외입니다. MySQL 서버 자체는 이 기능을 구현하지 않기 때문에 외래 키 정의를 구문 분석합니다). 서로 다른 스토리지 엔진은 서로 통신하지 않지만 단순히 응답합니다. 상위 계층 서버 요청에.

연결 관리 및 보안

각 클라이언트 연결에는 서버 프로세스에 스레드가 있습니다. 이 연결에 대한 쿼리는 이 별도의 스레드에서만 실행되며, 실행 중인 스레드에서만 실행됩니다. 특정 CPU 코어 또는 CPU. 서버는 스레드 캐싱을 담당하므로 새 연결마다 스레드를 생성하거나 삭제할 필요가 없습니다. (참고: MySQL 5.5 이상에서는 스레드 풀 플러그인을 지원하는 API를 제공합니다. 이 플러그인은 풀에서 적은 수의 스레드를 사용하여 많은 수의 연결을 제공할 수 있습니다.)

클라이언트(애플리케이션)가 MySQL 서버에 연결되면 서버에서 이를 인증해야 합니다. 인증은 사용자 이름, 원래 호스트 정보 및 비밀번호를 기반으로 합니다. 보안 소켓(SSL) 연결을 사용하는 경우 X.509 인증서 인증도 사용할 수 있습니다. 클라이언트가 성공적으로 연결되면 서버는 클라이언트가 특정 쿼리에 대한 권한을 가지고 있는지 계속해서 확인합니다(예: 클라이언트가 세계 데이터베이스의 국가 테이블에서 SELECT 문을 실행할 수 있는지 여부).

최적화 및 실행

MySQL은 쿼리를 구문 분석하고 내부 데이터 구조(파싱 트리)를 생성한 다음 쿼리 재작성, 쿼리 읽기 순서 결정 등 다양한 최적화를 수행합니다. 테이블, 적절한 인덱스 선택 등 사용자는 특별한 키워드 힌트를 통해 최적화 프로그램의 의사 결정 프로세스에 영향을 미칠 수 있습니다. 또한 최적화 프로세스의 다양한 요소에 대한 설명을 최적화 프로그램에 요청하여 서버가 어떻게 최적화 결정을 내리는지 사용자가 알 수 있도록 하고, 사용자가 쿼리 및 스키마를 재구성하고 관련 구성을 수정하여 애플리케이션을 효율적으로 만들 수 있도록 참조 벤치마크를 제공할 수 있습니다. 가능한 한 실행하십시오.

옵티마이저는 어떤 스토리지 엔진이 사용되는지 상관하지 않지만 스토리지 엔진은 쿼리 최적화에 영향을 미칩니다. 옵티마이저는 스토리지 엔진에 특정 작업의 용량이나 비용 정보, 테이블 데이터의 통계 정보 등을 요청합니다. 예를 들어, 특정 스토리지 엔진의 특정 인덱스는 특정 쿼리에 대해 최적화될 수 있습니다.

SELECT 문의 경우 서버는 쿼리를 파싱하기 전에 먼저 쿼리 캐시(Query Cache)를 확인하고, 해당 쿼리가 있으면 서버가 쿼리 전체 과정을 수행할 필요가 없습니다. 구문 분석, 최적화 및 실행 대신 쿼리 캐시에 설정된 결과가 직접 반환됩니다.

위는 [MySQL] MySQL 논리 아키텍처의 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!