안녕하세요 여러분! 첫 글입니다.
이 글에서는 SQL 쿼리문이 어떻게 실행되는지 소개하겠습니다
다음은 MySQL 아키텍처 다이어그램입니다.
일반적으로 MySQl은 서버와 스토리지 엔진 계층의 두 부분으로 나눌 수 있습니다.
서버 레이어에는 커넥터, 쿼리 캐시, 파서, 옵티마이저, 실행기 등이 포함되며 MySQL의 핵심 서비스 기능 대부분과 모든 내장 기능(예: 날짜, 시간, 수학 및 암호화)이 포함되어 있습니다. 기능). 저장 프로시저, 트리거, 뷰 등 모든 교차 스토리지 엔진 기능이 이 레이어에서 구현됩니다.
스토리지 엔진 계층은 데이터 저장 및 검색을 담당합니다. 아키텍처는 플러그인 기반이며 InnoDB, MyISAM, Memory와 같은 여러 스토리지 엔진을 지원합니다. MySQL 5.5.5부터 InnoDB는 MySQL의 기본 스토리지 엔진이 되었습니다.
engine=memory와 함께 create table 문을 사용하여 테이블을 생성하도록 메모리 엔진을 지정할 수 있습니다.
다른 스토리지 엔진이 동일한 서버 계층을 공유함
첫 번째 단계는 커넥터가 필요한 데이터베이스를 연결하는 것입니다. 커넥터는 클라이언트와의 연결 설정, 권한 획득, 연결 유지 및 관리를 담당합니다. 연결 명령은 다음과 같습니다.
mysql -h$ip -P$port -u$user -p
이 명령은 서버와 연결을 설정하는 데 사용됩니다. 클래식 TCP 핸드셰이크를 완료한 후 커넥터는 공급자 사용자 이름과 비밀번호를 사용하여 신원을 인증합니다.
즉, 연결이 성공적으로 설정되면 관리자가 사용자 권한을 변경해도 기존 연결 권한에는 영향을 미치지 않습니다. 새로운 연결만 업데이트된 권한 설정을 사용합니다.
연결이 설정된 후 후속 작업이 없으면 연결은 유휴 상태로 전환되며, 이는 show processlist 명령을 사용하여 확인할 수 있습니다.
클라이언트가 너무 오랫동안 비활성 상태로 유지되면 커넥터 연결이 자동으로 끊어집니다. 기간은 wait_timeout 매개변수에 의해 제어되며 기본값은 8시간입니다.
연결이 종료되고 클라이언트가 요청을 보내면 다음과 같은 오류 메시지가 표시됩니다. 쿼리하는 동안 MySQL 서버에 대한 연결이 끊겼습니다. 계속하려면 다시 연결한 후 요청을 실행해야 합니다.
데이터베이스에서 지속적 연결은 클라이언트가 성공적으로 연결한 후에도 지속적인 요청에 대해 동일한 연결을 유지하는 것을 의미합니다. 짧은 연결이란 몇 번의 쿼리 후에 연결이 끊겼다가 후속 쿼리를 위해 다시 연결되는 것을 의미합니다.
연결 프로세스가 복잡하므로 개발 중에는 연결 생성을 최소화하는 것이 좋습니다. 즉, 가능하면 영구 연결을 사용하는 것이 좋습니다.
그러나 영구 연결을 사용하는 경우 실행 중에 사용되는 임시 메모리가 연결 개체 내에서 관리되므로 MySQL의 메모리 사용량이 크게 증가할 수 있습니다. 이러한 리소스는 연결이 종료될 때만 해제됩니다. 지속적인 연결이 누적되면 과도한 메모리 사용으로 이어져 시스템이 강제로 MySQL(OOM)을 종료하고 예기치 않게 다시 시작될 수 있습니다.
솔루션:
참고: MySQL 8.0부터 쿼리 캐시 기능은 장점보다 단점이 더 크기
기 때문에 완전히 제거되었습니다.
MySQL은 쿼리 요청을 받으면 먼저 쿼리 캐시를 확인하여 이 쿼리가 이전에 실행되었는지 확인합니다. 이전에 실행된 쿼리와 그 결과는 키-값 쌍으로 메모리에 캐시됩니다. 키는 쿼리문이고 값은 결과입니다. 쿼리 캐시에서 키가 발견되면 해당 값이 클라이언트에 직접 반환됩니다.
쿼리 캐시에 쿼리가 없으면 프로세스가 계속됩니다.
쿼리 캐시가 득보다 실이 더 많은 이유는 무엇입니까?
쿼리 캐시 무효화가 매우 자주 발생합니다. 테이블을 업데이트하면 해당 테이블과 관련된 모든 쿼리 캐시가 지워지므로 테이블이 정적 구성 테이블이 아닌 이상 캐시 적중률이 매우 낮습니다.
MySQL은 쿼리 캐시를 사용하기 위한 "주문형" 방법을 제공합니다. query_cache_type 매개변수를 DEMAND로 설정하면 SQL 문은 기본적으로 쿼리 캐시를 사용하지 않습니다. 쿼리 캐시를 사용하려면 SQL_CACHE를 명시적으로 지정할 수 있습니다.
mysql -h$ip -P$port -u$user -p
쿼리 캐시에 적중되지 않으면 명령문 실행 프로세스가 시작됩니다. MySQL은 먼저 수행할 작업을 이해해야 SQL 문을 구문 분석합니다.
파서는 먼저 어휘 분석을 수행합니다. 문자열과 공백으로 구성된 입력 SQL 문은 MySQL에서 분석되어 각 부분이 무엇을 나타내는지 식별합니다. 예를 들어 select는 쿼리문으로, T는 테이블 이름으로, ID는 열로 식별됩니다.
어휘 분석 후 구문 분석이 수행됩니다. 구문 분석기는 어휘 분석 결과를 바탕으로 SQL 문이 MySQL의 구문 규칙을 준수하는지 여부를 판단합니다.
구문 오류가 있는 경우 SQL 구문에 오류가 있습니다.라는 오류 메시지가 표시됩니다. 예를 들어 다음 쿼리에서는 select 키워드의 철자가 잘못되었습니다.
select SQL_CACHE * from T where ID=10;
파싱 후 MySQL은 사용자가 무엇을 하려는지 알고 있습니다. 다음으로 최적화 프로그램이 이를 수행하는 방법을 결정합니다.
옵티마이저는 테이블에 여러 인덱스가 있을 때 사용할 인덱스를 결정하거나, 쿼리에 여러 테이블이 포함될 때 테이블 조인 순서를 결정합니다. 예를 들어 다음 쿼리에서는:
mysql> elect * from t where ID=1; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'elect * from t where ID=1' at line 1
쿼리는 t1 또는 t2에서 값을 검색하여 시작할 수 있습니다. 두 접근 방식 모두 동일한 논리적 결과를 산출하지만 성능은 다를 수 있습니다. 옵티마이저의 역할은 가장 효율적인 계획을 선택하는 것입니다.
최적화 단계 이후에는 Executor로 프로세스가 진행됩니다.
실행자가 쿼리 실행을 시작합니다.
실행 전 먼저 현재 연결에 테이블 쿼리 권한이 있는지 확인합니다. 그렇지 않은 경우 권한이 부족하다는 오류가 반환됩니다. (쿼리 캐시에서 결과를 반환할 때도 권한 확인이 수행됩니다.)
권한이 부여되면 테이블이 열리고 실행이 계속됩니다. 이 프로세스 동안 실행자는 테이블의 엔진 정의를 기반으로 스토리지 엔진과 상호 작용합니다.
예를 들어 테이블 T에 ID 열에 대한 인덱스가 없다고 가정합니다. Executor의 실행 과정은 다음과 같습니다.
이제 쿼리가 완료되었습니다.
인덱싱된 테이블의 경우 프로세스에는 엔진의 사전 정의된 방법을 사용하여 "첫 번째 일치 행"과 "다음 일치 행"을 반복적으로 가져오는 작업이 포함됩니다.
느린 쿼리 로그에서 행_검사 필드는 쿼리 실행 중 스캔된 행 수를 나타냅니다. 이 값은 실행자가 데이터 행을 검색하기 위해 엔진을 호출할 때마다 누적됩니다.
어떤 경우에는 실행기에 대한 단일 호출에 엔진 내부적으로 여러 행을 검색하는 작업이 포함될 수 있습니다. 따라서 엔진에서 스캔한 행 수가 반드시 Row_examined와 같지는 않습니다.
읽어주셔서 감사합니다! 이 글이 여러분에게 도움이 되기를 바랍니다.
위 내용은 SQL 쿼리 문은 어떻게 실행됩니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
