MySQL의 4가지 유형의 격리 수준에 대한 심층적인 이해

SQL 표준은 트랜잭션 내부 및 외부의 변경 사항이 표시되고 표시되지 않는 것을 제한하는 몇 가지 특정 규칙을 포함하여 4가지 유형의 격리 수준을 정의합니다. 격리 수준이 낮을수록 일반적으로 더 높은 동시성을 지원하고 시스템 오버헤드가 더 낮습니다.

Read Uncommitted(커밋되지 않은 콘텐츠 읽기)

이 격리 수준에서는 모든 트랜잭션을 볼 수 있습니다. 실행 결과 커밋되지 않은 다른 트랜잭션. 이 격리 수준은 성능이 다른 수준보다 그다지 좋지 않기 때문에 실제 응용 프로그램에서는 거의 사용되지 않습니다. 커밋되지 않은 데이터를 읽는 것을 더티 읽기(dirty read)라고도 합니다.
읽기 커밋됨

이는 대부분의 데이터베이스 시스템에 대한 기본 격리 수준입니다(MySQL 기본값은 아님). 이는 격리의 간단한 정의를 충족합니다. 트랜잭션은 커밋된 트랜잭션에 의해 변경된 내용만 볼 수 있습니다. 이 격리 수준은 소위 반복 불가능한 읽기도 지원합니다. 동일한 트랜잭션의 다른 인스턴스가 인스턴스 처리 중에 새로운 커밋을 가질 수 있으므로 동일한 선택이 다른 결과를 반환할 수 있기 때문입니다.
반복 읽기(반복 가능)

이는 MySQL의 기본 트랜잭션 격리 수준으로, 동일한 트랜잭션의 여러 인스턴스가 동시에 데이터를 읽을 수 있도록 보장합니다. , 동일한 데이터 행이 표시됩니다. 그러나 이론적으로 이는 또 다른 까다로운 문제, 즉 팬텀 읽기(Phantom Read)로 이어집니다. 간단히 말해서, 팬텀 읽기는 사용자가 특정 범위의 데이터 행을 읽을 때 다른 트랜잭션이 해당 범위에 새 행을 삽입하는 것을 의미합니다. 사용자가 해당 범위의 데이터 행을 다시 읽으면 새로운 "팬텀"이 있음을 알게 됩니다. 좋아요. InnoDB와 Falcon 스토리지 엔진은 다중 버전 동시성 제어(MVCC, Multiversion Concurrency Control) 메커니즘을 통해 이 문제를 해결합니다.

직렬화 가능
이는 가장 높은 격리 수준이며, 팬텀 읽기 문제가 발생하지 않도록 트랜잭션을 강제로 주문하여 해결됩니다. 즉, 읽은 각 데이터 행에 공유 잠금을 추가합니다. 이 수준에서는 시간 초과와 잠금 경합이 많이 발생할 수 있습니다.

이 네 가지 격리 수준은 서로 다른 잠금 유형을 사용하여 구현되므로 동일한 데이터를 읽으면 문제가 발생하기 쉽습니다. 예:

더티 읽기(Dirty Read): 트랜잭션이 데이터 일부를 업데이트했으며, 이때 다른 트랜잭션이 동일한 데이터를 읽었습니다. 어떤 이유로 이전 작업이 롤백인 경우. , 후자의 트랜잭션에서 읽은 데이터는 올바르지 않습니다.

반복 불가능한 읽기: 트랜잭션의 두 쿼리 간에 데이터가 일치하지 않습니다. 이는 두 쿼리 데이터 사이에 삽입된 트랜잭션에 의해 업데이트된 원본 데이터 때문일 수 있습니다.

팬텀 읽기: 트랜잭션의 두 쿼리에서 데이터 항목 수가 일치하지 않습니다. 예를 들어 한 트랜잭션은 여러 행의 데이터를 쿼리하는 반면 다른 트랜잭션은 이때 여러 개의 새로운 데이터를 쿼리합니다. 이전 트랜잭션의 후속 쿼리에서 이전에는 없었던 여러 데이터 열이 있음을 알 수 있습니다.

MySQL에서는 이러한 4가지 격리 수준이 구현되어 있으며 이로 인해 다음과 같은 문제가 발생할 수 있습니다.

다음으로 MySQL 클라이언트 프로그램을 사용하여 여러 격리 수준을 테스트하겠습니다. 테스트 데이터베이스는 test이고 테이블은 tx입니다. 테이블 구조:

id	int
num	int

id                                   int

번호

                                                                              int >

두 명령줄 클라이언트는 A와 B입니다. 이들은 A의 격리 수준을 지속적으로 변경하고 B 측의 데이터를 수정합니다.

(1) B의 데이터 전에서 uncommitted(uncommitted read)

를 읽도록 A의 격리 수준을 설정합니다. 업데이트됨:

클라이언트 A:

B 업데이트된 데이터:

고객 B:

고객 A:

위의 실험을 통해 트랜잭션 B가 레코드를 업데이트했지만 제출되지 않았다고 결론을 내릴 수 있습니다. 이때 트랜잭션 A는 커밋되지 않은 레코드를 쿼리할 수 있습니다. 더티 읽기가 발생합니다. 커밋되지 않은 읽기는 가장 낮은 격리 수준입니다.

(2) 클라이언트 A의 트랜잭션 격리 수준을 커밋된 읽기로 설정

B가 데이터를 업데이트하기 전 :

클라이언트 A:

B 업데이트 데이터:

고객 B:

고객 A:

위의 실험을 통해 커밋된 읽기 격리 수준이 더티 읽기 문제를 해결한다는 결론을 내릴 수 있습니다. 그러나 반복 불가능한 읽기 문제는 다음과 같습니다. 즉, 트랜잭션 B가 두 쿼리 사이의 데이터 조각을 업데이트했기 때문에 두 쿼리 사이에서 트랜잭션 A가 쿼리한 데이터가 일치하지 않습니다. 커밋된 읽기는 커밋된 레코드 읽기만 허용하며 반복 가능한 읽기는 필요하지 않습니다.

(3),

B에서 A의 격리 수준을 반복 읽기(repeatable read)로 설정

데이터가 업데이트되었습니다:

클라이언트 A:

B 업데이트 데이터:

고객 B:

고객 A:

B 삽입 데이터:

클라이언트 B:

클라이언트 A:

위의 실험을 토대로 반복 읽기 격리 수준은 커밋된 레코드의 읽기만 허용하며, 트랜잭션이 레코드를 두 번 읽는 동안 다른 트랜잭션이 레코드를 업데이트한다는 결론을 내렸습니다. 그러나 트랜잭션이 다른 트랜잭션과 직렬화될 필요는 없습니다. 예를 들어, 트랜잭션이 커밋된 트랜잭션에 의해 업데이트된 레코드를 찾을 수 있는 경우 팬텀 읽기 문제가 발생할 수 있습니다(데이터베이스가 격리 수준을 다르게 구현하기 때문에 이것이 가능하다는 점에 유의하세요). 위와 같은 실험에서는 데이터를 환상적으로 읽는 데 문제가 없습니다.

(4), A의 격리 수준을 직렬화 가능

A측이 거래를 개시하고 B측이 기록을 삽입합니다

거래 A측:

거래 B측:

왜냐하면 이때 트랜잭션 A의 격리 수준은 직렬화 가능으로 설정되어 있으며 트랜잭션을 시작한 후에는 커밋되지 않으므로 트랜잭션 B는 대기만 할 수 있습니다.

트랜잭션 A가 트랜잭션을 커밋합니다.

트랜잭션 A 측

거래 B면

 

직렬화 가능은 필드를 완전히 잠급니다. 트랜잭션이 동일한 데이터를 쿼리하는 경우 이전 트랜잭션이 완료되고 잠금이 해제될 때까지 기다려야 합니다. 은 완전한 격리 수준이며 해당 데이터 테이블을 잠그기 때문에 효율성 문제가 있습니다.

위 내용은 MySQL의 4가지 유형의 격리 수준에 대한 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!