MySQL 기본 스케줄링 전략에 대한 간략한 분석

[소개] MySQL을 사용하면 명령문의 일정 특성에 영향을 줄 수 있습니다. 이를 통해 여러 클라이언트의 쿼리가 더 잘 협력할 수 있으므로 단일 클라이언트가 너무 오랫동안 잠기지 않습니다. 일정 특성을 변경하면 특정 쿼리가 더 빠르게 처리될 수도 있습니다. 먼저 MySQL의 기본 스케줄링 정책을 살펴본 다음

을 살펴보겠습니다. MySQL을 사용하면 문의 스케줄링 특성에 영향을 줄 수 있으며, 이로 인해 여러 클라이언트의 쿼리가 더 잘 협력하게 되어 단일 클라이언트가 잠기지 않게 됩니다. 너무 오랫동안. 일정 특성을 변경하면 특정 쿼리가 더 빠르게 처리될 수도 있습니다. 먼저 MySQL의 기본 스케줄링 정책을 살펴본 다음 이 정책을 변경하는 데 사용할 수 있는 옵션을 살펴보겠습니다. 이 논의의 목적을 위해 검색(SELECT)을 수행하는 클라이언트 프로그램이 리더 프로그램이라고 가정합니다. 테이블 수정 작업(DELETE, INSERT, REPLACE 또는 UP DATE)을 수행하는 또 다른 클라이언트 프로그램은 작성기입니다.

MySQL의 기본 스케줄링 전략은 다음과 같이 요약할 수 있습니다.

◆쓰기 요청은 도착한 순서대로 처리되어야 합니다.

　◆읽는 것보다 쓰는 것이 우선입니다.

테이블 잠금을 사용하여 예약 전략을 구현합니다. 클라이언트 프로그램이 테이블에 액세스하려고 할 때마다 먼저 테이블에 대한 잠금을 얻어야 합니다. 이는 LOCK TABLES를 사용하여 직접 수행할 수 있지만 일반적으로 서버의 잠금 관리자는 필요할 때 자동으로 잠금을 획득합니다. 클라이언트가 테이블 처리를 마치면 테이블에 대한 잠금이 해제될 수 있습니다. 직접 획득한 잠금은 UNLOCK TABLES를 사용하여 해제할 수 있지만 서버는 획득한 잠금도 자동으로 해제합니다.

쓰기 작업을 수행하는 클라이언트는 테이블에 대한 배타적 접근 잠금을 가지고 있어야 합니다. 쓰기 작업이 진행되는 동안 테이블에서 데이터 레코드가 삭제, 추가 또는 변경되기 때문에 테이블은 일관성이 없는 상태가 되며 이에 따라 테이블의 인덱스도 업데이트해야 할 수 있습니다. 테이블이 지속적으로 변경되는 경우 이때 다른 클라이언트가 테이블에 액세스하도록 허용하면 문제가 발생할 수 있습니다. 두 클라이언트가 동시에 동일한 테이블에 쓰는 것은 좋지 않습니다. 이렇게 하면 테이블을 빠르게 사용할 수 없게 되기 때문입니다. 클라이언트가 변경 테이블을 읽도록 허용하는 것도 좋지 않습니다. 테이블을 읽는 순간 테이블이 변경되어 결과가 올바르지 않을 수 있기 때문입니다. 읽기 작업을 수행하는 클라이언트에는 테이블 읽기 프로세스 중에 테이블이 변경되지 않도록 하기 위해 다른 클라이언트가 테이블에 쓰는 것을 방지하는 잠금이 있어야 합니다. 그러나 잠금은 읽기 작업에 대한 독점 액세스를 제공할 필요가 없습니다. 또한 이 잠금을 통해 다른 클라이언트가 동시에 테이블에서 읽을 수 있습니다. 읽어도 테이블이 변경되지 않으므로 다른 클라이언트가 테이블을 읽는 것을 막을 필요가 없습니다.

MySQL에서는 일정 전략에 영향을 주는 여러 쿼리 제한 수정자를 허용합니다. 그 중 하나는 DELETE, INSERT, LOAD DATA, REPLACE 및 UP DATE 문에 대한 LOW_PRIORITY 키워드입니다. 다른 하나는 SELECT 문의 HIGH_PRIORITY 키워드입니다. 세 번째는 INSERT 및 REPLACE 문의 DELAYED 키워드입니다.

LOW_PRIORITY 키워드는 스케줄링에 다음과 같은 영향을 미칩니다. 일반적으로 테이블을 읽는 동안 테이블에 대한 쓰기가 도착하면 판독기가 완료될 때까지 쓰기가 차단됩니다. 쿼리가 시작되면 중단할 수 없기 때문입니다. Writer가 기다리는 동안 다른 읽기 요청이 도착하면 기본 예약 정책에 따라 Writer에 리더보다 높은 우선 순위가 부여되므로 리더도 차단됩니다. 첫 번째 읽기 프로그램이 끝나면 쓰기 프로그램이 계속되고, 이 쓰기 프로그램이 끝나면 두 번째 읽기 프로그램이 시작됩니다.

쓰기 요청이 LOW_PRIORITY 요청인 경우 쓰기 작업은 읽기 작업보다 우선순위가 높은 것으로 간주되지 않습니다. 이 경우, Writer가 대기하는 동안 두 번째 읽기 요청이 도착하면 두 번째 읽기 작업이 대기 중인 쓰기 작업보다 먼저 대기하도록 합니다. 작성자는 다른 읽기 요청이 없는 경우에만 실행이 허용됩니다. 이러한 일정 변경의 이론적 의미는 LOW_PRIORITY 쓰기가 영원히 차단될 수 있다는 것입니다. 이전 읽기 요청이 처리되는 동안 다른 읽기 요청이 도착할 때마다 이 새 요청은 LOW_PRIORITY 쓰기 전에 대기열에 들어갈 수 있습니다.

SELECT 쿼리의 HIGH_PRIORITY 키워드도 비슷한 효과를 갖습니다. 쓰기 작업의 우선 순위가 보통인 경우에도 보류 중인 쓰기 작업 전에 SELECT가 삽입됩니다. INSERT의 ELAYED 수정자는 테이블에 대한 INSERT DELAYED 요청이 도착하면 서버는 해당 행을 대기열에 넣고 즉시 클라이언트 프로그램에 상태를 반환하므로 이러한 경우에도 클라이언트 프로그램은 계속 실행할 수 있습니다. 행 아직 테이블에 삽입되지 않았습니다. 판독기가 테이블에서 읽는 중인 경우 대기열의 행은 보류 중입니다. 읽기가 없으면 서버는 지연된 행 큐에 행을 삽입하기 시작합니다. 때때로 서버는 새로운 읽기 요청이 도착했는지 확인하기 위해 중지하고 기다립니다. 그렇다면 지연된 행 큐가 일시 중단되고 판독기가 계속 진행되도록 허용됩니다. 다른 읽기 작업이 없으면 서버는 지연된 행 삽입을 다시 시작합니다. 이 프로세스는 지연된 대기열이 빌 때까지 계속됩니다.

일부 MySQL 버전에는 나타나지 않습니다. 다음 표에는 이러한 수정자와 이를 지원하는 MySQL 버전이 나열되어 있습니다. 이 표를 사용하여 사용 중인 MySQL 버전에 어떤 기능이 있는지 확인할 수 있습니다.

INSERT DELAYED는 다른 클라이언트가 긴 SELECT 문을 실행할 수 있고 삽입이 완료될 때까지 기다리지 않으려는 경우 유용합니다. INSERT DELAYED를 발행한 클라이언트는 서버가 삽입할 행을 삽입하기만 하면 되므로 더 빠르게 실행을 계속할 수 있습니다. 그러나 일반 INSERT와 INSERT DELAYED 성능의 차이점을 알고 있어야 합니다. INSERT DELAYED에 구문 오류가 있으면 클라이언트에 오류가 전송됩니다. 정상이면 메시지가 전송되지 않습니다. 예를 들어, 이 문이 반환될 때 얻은 AUTO_INCREMENT 값은 신뢰할 수 없습니다. 또한 고유 인덱스의 중복 개수도 확인할 수 없습니다. 이는 실제 삽입이 완료되기 전에 삽입 작업이 상태를 반환하기 때문에 발생합니다. 다른 것들은 INSERT DELAYED 문의 행이 삽입을 위해 대기하고 서버가 충돌하거나 종료되면(kill -9 사용) 이러한 행이 손실된다는 것을 나타냅니다. 일반적인 TERM 종료에서는 이 작업이 수행되지 않으며 서버는 종료하기 전에 이러한 행을 삽입합니다.

위 내용은 MySQL 기본 스케줄링 전략에 대한 간략한 분석입니다. 자세한 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!