전체 아키텍처

MySQL 아키텍처 구성요소란 무엇입니까?

1. 커넥터

커넥터는 주로 클라이언트와의 연결 설정, 권한 확인 및 연결 관리를 담당합니다. show processlist 명령을 사용하여 연결 정보를 볼 수 있습니다. 사용자 연결이 성공적으로 생성되면 권한 정보가 메모리로 읽혀집니다. 나중에 사용자 권한이 수정되면 새로 고치지 않으면 적용되지 않습니다.

연결의 경우 오랫동안(유휴 상태) 명령이 수신되지 않으면 커넥터는 일정 시간이 지난 후 링크를 끊습니다. 이 시간은 wait_timeout 매개변수에 의해 제어되며 기본값은 8시간입니다.

커넥터의 연결은 긴 연결과 짧은 연결로 구분됩니다.

긴 연결: 연결이 성공한 후 클라이언트가 동일한 연결을 사용하도록 요청합니다.
짧은 연결: 각 연결이 끝날 때마다 연결이 끊어집니다. 요청이 다시 실행되면 연결이 다시 설정됩니다

평상시에는 자주 반복적으로 연결을 생성하는 오버헤드를 피하기 위해 일반적으로 긴 연결을 사용합니다. 연결을 끊지 않고 오랫동안. 그러나 연결은 사용 중에 차지하는 일부 메모리를 관리하며 연결이 끊어지면 연결과 함께 해제된다는 점에 유의해야 합니다. 연결이 끊기지 않고 오랫동안 처리 없이 계속 누적되면 과도한 메모리 사용량이 발생하여 시스템에 의해 강제로 종료될 수 있습니다. 일반적으로 두 가지 해결 방법이 있습니다.

정기적으로 긴 연결을 끊고, 일정 시간이 지난 후 또는 많은 메모리를 차지하는 쿼리를 실행한 후 연결을 끊고, 이로 인해 메모리가 해제되고, 쿼리가 필요할 때 연결을 다시 생성합니다
5.7 이후 버전에서는 mysql_reset_connection을 사용하여 재연결 및 권한 확인 없이 연결 리소스를 다시 초기화하고 연결이 생성된 상태로 복원할 수 있습니다. 동시에 테이블 잠금 해제, 임시 테이블 삭제, 세션에 설정된 변수 재설정 등의 다른 효과도 있을 것입니다.

2. 쿼리 캐시

참고: 쿼리 캐시는 이후 폐지되었습니다. 버전 8.0

연결이 성공적으로 생성되었습니다. 이후에는 SQL 문을 실행할 수 있습니다. 그러나 쿼리 캐시가 켜져 있으면 실제로 SQL을 분석하기 전에 캐시에서 쿼리가 쿼리됩니다. 직접 반환됩니다. 쿼리 캐시는 키-값 구조입니다. 여기서 Key는 SQL 문이고 Value는 해당 쿼리 결과입니다. 캐시가 누락되면 후속 쿼리 작업이 계속됩니다. 쿼리가 완료된 후 결과는 쿼리 캐시에 저장됩니다.

쿼리 캐시는 왜 삭제되나요? 쿼리 캐싱은 일반적으로 득보다 실이 더 많기 때문입니다. 테이블이 업데이트되면 해당 테이블에 해당하는 쿼리 캐시가 지워지며, 자주 업데이트되는 테이블의 경우 쿼리 캐시가 매우 자주 무효화되어 기본적으로 캐시 업데이트에 따른 오버헤드도 발생합니다. 기본적으로 변경되지 않은 데이터 테이블의 경우 시스템 구성 테이블과 같은 쿼리 캐싱을 사용하도록 선택할 수 있습니다. 외부 캐싱도 사용합니다.

query_cache_type 매개변수를 통해 쿼리 캐시를 구성할 수 있습니다. 이 매개변수에는 다음과 같은 3가지 선택적 값이 있습니다.

0: 쿼리 캐시 끄기
1: 쿼리 캐시 켜기
2 : SQL_CACHE 키워드를 사용할 때 쿼리 캐시를 사용하는 경우, 예를 들어 select SQL_CACHE * from t where

3. 분석기

쿼리 캐시가 적중되지 않으면 실제로 SQL을 실행해야 합니다. 그리고 실행 전에 SQL을 구문 분석해야 합니다. 이 구문 분석은 주로 어휘 분석과 구문 분석의 두 단계로 나뉩니다.

어휘 분석: SQL에서 select, from, 테이블 이름, 필드 이름 등의 키워드를 추출합니다.
문법 분석: 어휘 분석 결과와 일부 문법을 기반으로 SQL 문법이 적법한지 확인합니다. MySQL에서 정의한 규칙에 따라 추상 구문 트리(AST)가 결국 생성됩니다

4. 최적화 프로그램

최적화 프로그램은 분석기가 생성한 AST를 입력으로 사용하여 SQL을 최적화하고 최적화 프로그램이 간주하는 것을 생성합니다. 실행자에게 전달되는 최적의 실행 계획이 실행됩니다. 최적화 프로세스에는 SQL의 논리적 변환과 비용 계산이 포함됩니다.

논리적 변환은 Java의 정적 컴파일 시간 최적화와 유사하며, SQL 변환 전후에 일관된 실행 결과를 보장하기 위해 SQL을 "단순화"합니다. 예를 들어, 1=1이고 a.id = 2인 경우는 a.id = 2인 경우와 동일할 수 있습니다.

비용 계산의 주요 목적은 인덱스 사용 여부, 어떤 인덱스를 사용할지, 다중 테이블 연결 시 어떤 순서를 사용할지 등 SQL 실행 방법을 선택하는 것입니다. 비용은 서비스 계층 비용과 엔진 계층 비용으로 구분됩니다. 서비스 계층 비용은 주로 CPU와 관련되고, 엔진 계층 비용은 주로 디스크 I/O와 관련됩니다. MySQL 5.7에서는 이 두 가지 비용을 구성하기 위해 mysql.server_cost와 mysql.engine_cost 두 개의 시스템 테이블을 도입합니다. 테이블에 구성되는 것은 임시 테이블 생성, 정렬, 페이지 읽기 등 다양한 작업에 해당하는 비용입니다.

Optimizer는 생성된 쿼리 계획과 위의 두 가지 비용 구성을 기반으로 쿼리 계획의 최종 비용을 계산하고, 여러 쿼리 계획 중 비용이 가장 작은 것을 선택하여 Executor에 실행합니다. 그러나 때로는 비용이 가장 적다고 해서 반드시 실행 시간이 가장 짧은 것은 아니라는 점에 유의해야 합니다.

5. Executor

Executor는 옵티마이저가 선택한 쿼리 계획에 따라 SQL을 실행하기 전에 요청한 사용자에게 해당 쿼리 권한이 있는지 확인하고 마지막으로 MySQL 엔진 계층에서 제공하는 인터페이스를 호출합니다. SQL 문을 실행하고 결과를 반환합니다. 쿼리 캐싱이 활성화된 경우 결과는 쿼리 캐시에도 저장됩니다.