MySQL의 잠금과 관련된 문제에 대한 자세한 설명

데이터베이스에 동시에 액세스하는 방법은 무엇인가요? 정답은 加锁 입니다.

추천: "mysql 비디오 튜토리얼 "

다음으로, 데이터베이스의 잠금 메커니즘에 대해 이야기해 보겠습니다. ?

우선 잠금은 동시성 제어 기술입니다. 잠금은 여러 사용자가 동시에 동일한 데이터에 액세스할 때 데이터를 보호하는 데 사용됩니다.

두 가지 기본 잠금 유형이 있습니다.

공유(S) 잠금: 여러 트랜잭션이 공유 페이지를 차단할 수 있습니다. 수정할 수 없습니다. 일반적으로 S 잠금은 페이지를 읽은 후 즉시 해제됩니다. select 문 실행 시 Operation 객체(테이블 또는 일부 레코드)에 공유 잠금을 추가해야 하는데, 잠금을 추가하기 전에 배타적 잠금이 있는지 확인해야 합니다. 그렇지 않은 경우 공유 잠금을 추가할 수 있습니다. (N개의 공유 잠금을 객체에 추가할 수 있습니다.) 그렇지 않으면 작동하지 않습니다. 공유 잠금은 일반적으로 select 문을 실행한 후 해제됩니다. 물론, 주로 데이터베이스에서 설정한 트랜잭션 격리 수준에 따라 트랜잭션이 종료될 때(정상 종료 및 비정상 종료 포함) 해제될 수도 있습니다.

배타적(X) 잠금: 단 하나의 트랜잭션만 이 페이지를 차단할 수 있습니다. 다른 트랜잭션은 페이지에 액세스하기 전에 X 잠금이 해제될 때까지 기다려야 합니다. 거래. insert, update, delete 문을 실행할 때, 동작 중인 객체에 배타적 잠금을 추가해야 하며, 배타적 잠금을 추가하기 전에 해당 개체에 다른 잠금이 없는지 확인해야 합니다. 객체에 다른 잠금을 추가할 수 없습니다. 배타적 잠금은 일반적으로 트랜잭션이 끝날 때 해제됩니다(물론 데이터베이스 트랜잭션 격리 수준이 커밋되지 않은 읽기(커밋되지 않은 데이터 읽기)로 설정된 경우 예외도 있습니다. 이 경우 배타적 잠금은 트랜잭션이 끝난 후 해제됩니다. 업데이트 작업이 완료됨) 릴리스되며 트랜잭션이 끝날 때가 아닙니다.

프레스 잠금 장치

자물쇠를 사용하기 때문에 교착상태가 발생할 가능성이 있습니다.

교착 상태에 필요한 네 가지 조건:

상호 배타적 조건: 리소스는 한 번에 하나의 프로세스에서만 사용할 수 있습니다.

요청 및 보관 조건: 리소스 요청으로 인해 프로세스가 차단되면 획득한 리소스를 보관합니다.

비박탈 조건: 프로세스를 통해 얻은 자원은 모두 사용되기 전에 강제로 박탈될 수 없습니다.

루프 대기 조건: 여러 프로세스가 리소스 관계를 기다리는 일대일 루프를 형성합니다.

시스템에 교착상태가 발생하는 한 이러한 조건이 true여야 하며, 위 조건 중 하나라도 충족되지 않는 한 교착상태는 발생하지 않습니다.

교착상태 방지

교착상태 발생을 방지하려면 교착상태 발생에 필요한 4가지 조건 중 하나만 파괴하면 됩니다. .

1) 상호 배제 조건을 파괴합니다

모든 ​​시스템 리소스를 공유하도록 허용하면 시스템이 교착 상태에 들어가지 않습니다. 그러나 일부 리소스는 동시에 액세스할 수 없습니다. 프린터와 같은 중요한 리소스는 상호 배타적으로만 사용할 수 있습니다. 따라서 교착상태를 방지하기 위해 상호 배제 조건을 파괴하는 것은 불가능하며 경우에 따라 이러한 상호 배타성을 보호해야 합니다.

2) 양도할 수 없는 조건을 파괴합니다

양도할 수 없는 리소스를 일부 보유하고 있는 프로세스가 새로운 리소스를 요청하지만 만족할 수 없는 경우 이미 있는 리소스를 해제해야 합니다. 모든 리소스는 보유되고 다시 반환됩니다. -추후 필요시 적용됩니다. 이는 프로세스가 이미 점유한 리소스가 일시적으로 해제되거나 박탈되거나 이로 인해 양도할 수 없는 조건을 위반한다는 의미입니다.

이 전략은 구현하기 복잡합니다. 리소스를 반복적으로 신청하고 해제하면 시스템 오버헤드가 증가하고 시스템 처리량이 감소하므로 이전 단계의 작업이 실패할 수 있습니다. 이 방법은 CPU 레지스터, 메모리 자원 등 상태를 저장하고 복원하기 쉬운 자원에 주로 사용됩니다. 일반적으로 프린터와 같은 자원에는 사용할 수 없습니다.

3) 요청 및 보류 조건 파기

사전정적 할당 방식, 즉 프로세스가 실행되기 전에 한 번에 필요한 모든 리소스에 대해 프로세스가 적용됨 .자원이 충분할 때 만족할 때까지 작동하지 마십시오. 일단 작동되면 이러한 리소스는 항상 해당 리소스의 소유가 되며 다른 리소스 요청이 발생하지 않으므로 시스템이 교착 상태에 빠지지 않습니다.

이 방법은 구현이 간단하지만 단점도 분명합니다. 시스템 리소스가 심각하게 낭비됩니다. 이러한 리소스 중 일부는 실행 시작 시 또는 실행이 끝날 무렵에만 사용될 수 있습니다. 또는 전혀 사용되지 않습니다. 또한 특정 리소스가 다른 프로세스에 의해 오랫동안 점유되면 해당 리소스를 기다리는 프로세스의 실행 시작이 지연됩니다.

4) 루프 대기 조건 파괴

루프 대기 조건을 파괴하기 위해서는 순차적 자원 할당 방법을 사용할 수 있습니다. 먼저, 시스템의 자원에 번호를 매기고, 각 프로세스는 숫자가 증가하는 순서대로 자원을 요청해야 하며, 유사한 자원은 모두 한꺼번에 요청할 수 있다고 규정합니다. 즉, 자원 Ri를 할당하기 위해 프로세스가 적용되는 한, 해당 프로세스는 향후 자원 신청에서 Ri보다 큰 숫자의 자원에만 적용될 수 있습니다.

이 방법의 문제점은 번호 지정이 상대적으로 안정적이어야 한다는 것입니다. 이로 인해 대부분의 작업에서 리소스 번호를 지정할 때 실제로 이러한 리소스를 사용하는 순서가 고려되지만, 이는 새로운 유형의 장비 추가를 제한합니다. 작업이 리소스를 사용하는 순서가 시스템에서 지정한 순서와 달라서 리소스가 낭비되는 경우가 발생할 수 있습니다. 또한, 지정된 순서대로 리소스를 신청하는 방식은 필연적으로 사용자의 프로그래밍에 문제를 일으킬 수 있습니다.

Release 교착 상태

　1) 교착 상태 프로세스에서 리소스를 박탈합니다.

　2) 일부 또는 전체 프로세스를 종료합니다. ;

MySQL 잠금 세분성(즉, 잠금 수준)

MySQL 스토리지 엔진은 세 가지 유형(수준)을 사용합니다. 잠금 메커니즘: 행 수준 잠금, 페이지 수준 잠금과 테이블 수준 잠금.

1. 테이블 수준 잠금: 전체 테이블을 직접 잠급니다. 잠금 기간 동안 다른 프로세스는 테이블에 쓸 수 없습니다. 쓰기 잠금이 있으면 다른 프로세스는 읽을 수 없습니다. 특징: 낮은 오버헤드, 빠른 잠금, 가장 큰 잠금 세분성, 가장 높은 잠금 충돌 가능성 및 가장 낮은 동시성.

MyISAM 스토리지 엔진은 테이블 수준 잠금을 사용합니다.

테이블 공유 읽기 잠금과 테이블 독점 쓰기 잠금의 두 가지 모드가 있습니다. 읽기 잠금 추가 명령: lock table table name 읽기 잠금 제거 명령: Unlock tables.

동시 삽입 지원: 쿼리 및 삽입 작업이 동시에 실행되도록 지원합니다(테이블 끝에 동시 삽입).

잠금 예약 메커니즘: 쓰기 잠금 우선순위. 프로세스는 MyISAM 테이블에 대한 읽기 잠금을 요청하고 동시에 다른 프로세스도 동일한 테이블에 대한 쓰기 잠금을 요청합니다. MySQL은 이를 어떻게 처리합니까? 대답은 쓰기 프로세스가 먼저 잠금을 획득한다는 것입니다.

2. 행 수준 잠금: 지정된 레코드만 잠그므로 다른 프로세스가 동일한 테이블의 다른 레코드에 대해 계속 작업할 수 있습니다. 특징: 높은 오버헤드, 느린 잠금이 발생할 수 있습니다. 잠금 세분성은 가장 작고 잠금 충돌 가능성은 가장 낮으며 동시성은 가장 높습니다.

　　InnoDB 스토리지 엔진은 행 수준 잠금과 테이블 수준 잠금을 모두 지원하지만 기본적으로 행 수준 잠금이 사용됩니다.

3. 페이지 수준 잠금: 인접한 레코드 그룹을 한 번에 잠급니다. 오버헤드와 잠금 시간은 테이블 잠금과 행 잠금 사이에 있으며, 잠금 세분성은 테이블 잠금과 행 잠금 사이에 발생하며 동시성은 평균입니다.

여러 사용자의 동시 액세스를 처리하는 데 가장 일반적으로 사용되는 방법은 잠금입니다. 사용자가 데이터베이스의 개체를 잠그면 다른 사용자는 더 이상 해당 개체에 액세스할 수 없습니다. 동시 액세스에 대한 잠금의 영향은 잠금의 세분성에 반영됩니다. 예를 들어, (테이블 잠금) 테이블에 설정된 잠금은 전체 테이블에 대한 동시 액세스를 제한합니다. (페이지 잠금) 데이터 페이지에 설정된 잠금은 전체 데이터 페이지에 대한 액세스를 제한합니다. (행 잠금) 행에 설정된 잠금입니다. 잠금은 행에 대한 동시 액세스만 제한합니다.

낙관적 잠금과 비관적 잠금의 개념, 구현 방법 및 사용 시나리오

두 가지 잠금 메커니즘이 있습니다: 비관적 잠금과 낙관적 잠금.

비관적 잠금은 이름에서 알 수 있듯이 세상에 대해 비관적입니다. 변화하는 데이터에 다른 사람이 접근할 확률이 매우 높다고 믿기 때문에 데이터가 변경되기 시작하는 순간부터 데이터가 잠깁니다. 변경이 완료된 후에만 릴리스됩니다.

일반적인 데이터베이스 종속 비관적 잠금 호출:

select * from account where name="Erica" ​​​​업데이트

이 SQL 문 검색 조건(name="Erica")을 충족하는 계정 테이블의 모든 레코드가 잠깁니다. 이 트랜잭션이 커밋되기 전에(트랜잭션이 커밋되면 트랜잭션 중 잠금이 해제됨) 외부 세계에서 이러한 레코드를 수정할 수 없습니다. 이 문은 특정 행을 잠그는 데 사용됩니다(where 절이 있는 경우 where 조건을 충족하는 행입니다). 이러한 행이 잠겨 있으면 다른 세션에서 해당 행을 선택할 수 있지만 해당 문의 트랜잭션이 커밋 문이나 롤백 문에 의해 종료될 때까지 해당 행을 변경하거나 삭제할 수 없습니다. 업데이트를 위한 선택은 MySQL 트랜잭션 유형, 즉 시작 및 커밋에 배치되어야 하며 그렇지 않으면 작동하지 않는다는 점에 유의해야 합니다.

비관적인 태도로 인해 잠금 시간이 매우 길어지고 발행이 부실해지며, 특히 긴 거래로 인해 시스템의 전반적인 성능에 영향을 줄 수 있습니다.

비관적 잠금 구현 방법:

비관적 잠금도 데이터베이스 잠금 메커니즘을 기반으로 구현됩니다. 이러한 많은 잠금 메커니즘은 행 잠금, 테이블 잠금, 읽기 잠금, 쓰기 잠금 등과 같은 기존 관계형 데이터베이스에서 사용되며 작업 전에 모두 잠깁니다.

세상에 대해 상대적으로 낙관적인 낙관적 잠금은 변경된 데이터에 다른 사람이 접근할 확률이 매우 낮다고 믿기 때문에 수정이 완료되어 제출할 준비가 될 때까지 데이터가 잠기지 않습니다. 데이터베이스에 추가하면 객체를 읽고 변경할 때 객체가 잠기지 않으며 변경이 완료된 후 해제됩니다. 낙관적 잠금은 더티 읽기 문제를 해결할 수 없습니다.

낙관적 잠금의 잠금 시간은 비관적 잠금보다 짧아서 대규모 동시성에서 시스템의 전반적인 성능이 크게 향상됩니다.

낙관적 잠금 구현 방법:

1. 대부분은 데이터 버전(버전) 기록 메커니즘을 기반으로 하며, 각 데이터 행에 버전 식별자를 추가해야 합니다. (즉, 각 행의 데이터에는 버전이라는 필드가 하나 더 있음) 데이터가 업데이트될 때마다 해당 버전 번호 +1을 업데이트해야 합니다.

작동 원리: 데이터를 읽을 때 이 버전을 함께 읽고, 나중에 업데이트할 때 이 버전 번호에 하나를 추가하세요. 이때, 제출된 데이터의 버전 정보는 데이터베이스 테이블의 해당 레코드의 현재 버전 정보와 비교되며, 제출된 데이터의 버전 번호가 데이터베이스 테이블의 현재 버전 번호보다 큰 경우에는 해당 레코드의 버전 정보로 간주됩니다. 그렇지 않으면 만료된 데이터로 간주되어 다시 읽어야 합니다.

2. 타임스탬프를 사용하여 구현

낙관적 잠금 제어가 필요한 테이블에 필드를 추가하는 것도 마찬가지입니다. 이름은 중요하지 않으며 필드 유형은 타임스탬프를 사용합니다. 위 버전은 유사합니다. 업데이트가 제출되면 현재 데이터베이스의 데이터 타임스탬프를 확인하고 업데이트 이전에 얻은 타임스탬프와 비교합니다. 그렇지 않으면 버전 충돌입니다. .

비관적 잠금과 낙관적 잠금의 적용 가능한 시나리오:

동시성 양이 크지 않은 경우 비관적 잠금을 사용하여 문제를 해결할 수 있습니다. 동시성 문제; 그러나 시스템의 경우 동시성 양이 매우 크면 비관론은 매우 큰 성능 문제를 가져올 것이므로 낙관적 잠금 방법을 선택해야 합니다. 이제 대부분의 애플리케이션은 낙관적으로 잠겨야 합니다.

위 내용은 MySQL의 잠금과 관련된 문제에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!