MySQL 의 트 랜 잭 션 격 리 와 성능 에 미 치 는 영향 을 깊이 분석 합 니 다.

SQL 표준 은 4 가지 격 리 단 계 를 정 의 했 는데 구체 적 인 규칙 을 포함 하여 사무 내외 의 어떤 변화 가 보 이 는 지,어떤 것 이 보이 지 않 는 지 제한 했다.낮은 등급 의 격 리 급 은 일반적으로 더 높 은 병행 처 리 를 지원 하고 더 낮은 시스템 비용 을 가진다.
Uncommitted 읽 기(제출 되 지 않 은 내용 읽 기)
       이 격 리 단계 에 서 는 모든 사무 가 제출 되 지 않 은 다른 업무 의 실행 결 과 를 볼 수 있 습 니 다.이 격 리 단 계 는 다른 단계 보다 성능 이 별로 좋 지 않 기 때문에 실제 응용 에 사용 되 는 것 이 매우 적다.제출 되 지 않 은 데 이 터 를 읽 는 것 을 더러 운 읽 기(Dirty Read)라 고도 합 니 다.
Committed 읽 기(제출 내용 읽 기)
       이것 은 대부분의 데이터베이스 시스템 의 기본 격 리 단계 입 니 다.그것 은 격 리 의 간단 한 정 의 를 만족 시 켰 다.하나의 사 무 는 이미 제출 한 사무소 의 변화 만 볼 수 있다.이러한 격 리 단 계 는 중복 읽 기(Nonrepeatable Read)를 지원 합 니 다.같은 업무 의 다른 인 스 턴 스 가 이 인 스 턴 스 를 처리 하 는 동안 새로운 commt 가 있 을 수 있 기 때문에 같은 select 는 다른 결 과 를 되 돌려 줄 수 있 습 니 다.
반복 읽 기(다시 읽 기 가능)
       이것 은 MySQL 의 기본 트 랜 잭 션 격 리 단계 입 니 다.같은 트 랜 잭 션 의 여러 인 스 턴 스 가 동시에 데 이 터 를 읽 을 때 같은 데이터 줄 을 볼 수 있 도록 합 니 다.그러나 이론 적 으로 이것 은 또 다른 까다 로 운 문 제 를 초래 할 수 있다.즉,환 독(Phantom Read)이다.쉽게 말 하면 환 독 이란 사용자 가 특정한 범위 의 데이터 줄 을 읽 을 때 다른 사무 가 이 범위 에 새 줄 을 삽입 하 는 것 을 말한다.사용자 가 이 범위 의 데이터 줄 을 다시 읽 을 때 새로운'환영'줄 이 있 는 것 을 발견 할 수 있다.InnoDB 와 Falcon 메모리 엔진 은 다 중 버 전 병행 제어(MVCC,Multiversion Concurrency Control)메커니즘 을 통 해 이 문 제 를 해결 했다.
Serializable(직렬 화 가능) 
       이것 은 가장 높 은 격 리 단계 로 강제 적 인 업무 순 서 를 통 해 서로 충돌 하지 않 고 환 독 문 제 를 해결 할 수 있다.쉽게 말 하면 읽 는 데이터 줄 마다 공유 자 물 쇠 를 추가 하 는 것 이다.이 단계 에 서 는 대량의 시간 초과 현상 과 자물쇠 경쟁 을 초래 할 수 있다.
         이 네 가지 격 리 단 계 는 서로 다른 잠 금 형식 으로 이 루어 집 니 다.같은 데 이 터 를 읽 으 면 문제 가 발생 하기 쉽 습 니 다.예 를 들 면:

         더러 운 읽 기(Drity Read):어떤 사무 가 데 이 터 를 업 데 이 트 했 습 니 다.다른 사 무 는 이때 같은 데 이 터 를 읽 었 습 니 다.어떤 이유 로 앞의 Roll Back 이 작 동 하면 다음 사무소 에서 읽 은 데이터 가 정확 하지 않 습 니 다.

         중복 읽 을 수 없습니다(Non-repeatable read):한 업무 의 두 번 의 조회 에서 데이터 가 일치 하지 않 습 니 다.이것 은 두 번 의 조회 과정 에서 하나의 사무 가 업 데 이 트 된 기 존 데 이 터 를 삽입 한 것 일 수 있 습 니 다.

         환 독(Phantom Read):한 업무 의 두 번 의 조회 에서 데이터 펜 수가 일치 하지 않 습 니 다.예 를 들 어 한 업무 가 몇 열(Row)데 이 터 를 조 회 했 고 다른 업 무 는 이때 새로운 몇 열 데 이 터 를 삽입 하 였 습 니 다.이전의 업 무 는 다음 조회 에서 몇 열 데이터 가 이전에 없 었 던 것 임 을 발견 할 수 있 습 니 다.

         MySQL 에서 이 네 가지 격 리 단 계 를 실 현 했 는데 각각 다음 과 같은 문제 가 발생 할 수 있 습 니 다.

MySQL 트 랜 잭 션 격 리 단계 가 성능 에 미 치 는 영향
MySQL 은 기본적으로 세 단계 에서 작 동 합 니 다.우 리 는 업무 격 리 가 병행 작업 이 서로 영향 을 미 치지 않도록 데이터 의 불일치 성 을 유도 하 는 것 을 안다.그래서 데이터 의 일치 성 을 확보 하기 위해 사무 격 리 기능 을 도입 했다.상기 네 단계 의 데이터 에 대한 일치 성 보 호 는 점차적으로 향상 되 었 다.등급 4 는 업무 에 대한 격 리 효과 가 가장 좋 지만 성능 이 가장 나 빠 서 일반적으로 생산 환경 에서 사용 하지 않 는 다.
다음은 인 스 턴 스 를 통 해 서로 다른 단계 에서 MySQL 성능 이 받 은 영향 을 검증 합 니 다.나의 실험 환경 은:Redhat 5.8+MySQL 5.5
우선 세 션 두 개 를 사용 합 니 다.
1.등급 1 의 특성 검증
우리 가 session A 에서 진행 하 는 동작 은:

session B 에서 의 동작 은 session A 와 같 습 니 다.캡 처 를 추가 하지 않 습 니 다.
       이어서 우 리 는 일련의 실험 을 통 해 READ-UNCOMMITTED 가 도대체 무엇 인지,그것 이 도대체 어떤 특성 을 가지 고 있 는 지,우리 의 조작 에 어떤 영향 을 미 치 는 지 관찰 할 것 이다.우선,우 리 는 표 의 초기 데 이 터 를 다음 과 같이 볼 수 있다.

다음 에 우 리 는 session A 에서 그 중의 기록 을 변경 합 니 다.변경 결 과 는 다음 과 같 습 니 다.

메모:위 에서 사 무 를 사 용 했 지만,우 리 는 여기에서 commt 작업 을 하지 않 았 습 니 다.
 
다음 에 우 리 는 session B 에서 방금 고 친 표 에 대해 select 조 회 를 하고 조회 결 과 는 다음 과 같다.

비록 우 리 는 session A 의 결과 에 대해 commt 를 하지 않 았 지만 결 과 는 확실히 바 뀌 었 다 는 것 을 똑똑히 볼 수 있다.따라서 이런 단계 에서 제출 되 지 않 은 조작 은 데이터 의 일치 성에 영향 을 미친다.따라서 만약 에 우리 가 이때 session A 에서 상기 조작 을 스크롤 백 하면 우 리 는 이때 session B 의 결과 가 원래 의 결과 로 돌아 가 데이터 의 불일치 성 을 초래 한 것 을 발견 할 수 있다.이것 은 데이터 의 환 독 현상 이 라 고도 부 르 는데 매우 기괴 한 일이 다.따라서 어떤 장면 에서 우 리 는 이런 현상의 발생 을 피해 야 한다.그러나 이런 등급 도 그 용도 가 없 는 것 이 아니다.예 를 들 어 우리 가 대량의 데 이 터 를 기록 해 야 하고 읽 기 동작 이 적 을 때 이런 모델 을 사용 하기에 적합 하 다.
session A 가 스크롤 백 한 후에 session B 의 데이터 가 최초의 모습 으로 변 하 는 것 을 볼 수 있 습 니 다.이것 을 환 독 이 라 고도 합 니 다.

2.등급 READ COMMITTED 특성 검증
       먼저 session A 와 session B 의 격 리 단 계 를 모두 READ-COMMITTED 로 바 꾸 고 모두 사 무 를 시작 합 니 다.작업 은 다음 과 같 습 니 다.

다음은 tutors 표 의 초기 상태 정 보 를 살 펴 보 겠 습 니 다.

그리고 우 리 는 여전히 데이터 에 대해 업데이트 작업 을 하고 업데이트 후에 도 commt 가 없습니다.session A 에서 결과 가 바 뀌 었 음 을 볼 수 있 습 니 다.

이때 우 리 는 session B 에서 보 았 는데 결 과 는 여전히 변 하지 않 았 다.

그러나 만약 에 우리 가 이때 session A 에서 commt 작업 을 하면 우 리 는 session B 가 이때 조회 가 바 뀌 고 데이터 의 앞 뒤 가 일치 하지 않 으 며 데이터 의 환 독 도 초래 한 다 는 것 을 알 게 될 것 이다.

3.데이터 의 재 읽 기 가능
       데 이 터 를 다시 읽 을 수 있 고 REPEATABLE-READ 라 고도 합 니 다.이것 은 MySQL 이 기본적으로 사용 하 는 트 랜 잭 션 격 리 단계 로 장점 이 있 지만 데이터 의 일치 성 문 제 를 근본적으로 해결 하지 못 했 습 니 다.우선,이런 단계 에서 MySQL 이 어떻게 일 하 는 지,또 어떤 특성 이 있 는 지,우 리 는 어떻게 조작 해 야 하 는 지 테스트 해 보 자.
       우 리 는 먼저 REPEATABLE-READ 의 환경 을 설정 하고 구체 적 인 조작 방법 은 다음 과 같다.

그리고 우 리 는 그 초기 데 이 터 를 살 펴 보고 있 습 니 다.그 결 과 는 다음 과 같 습 니 다.

저 희 는 session A 에서 데 이 터 를 수정 하고 commt 를 진행 합 니 다.수정 한 결 과 는 다음 과 같 습 니 다.

그리고 세 션 B 에서 확인 해 보 니 결 과 는 변 함 이 없 었 습 니 다.

이것 은 다시 읽 을 수 있 는 기능 입 니 다.이번 세 션 이 제출 되 지 않 으 면 상대방 이 수정 하 더 라 도 결 과 는 변 하지 않 습 니 다.session B 에서 도 commt 작업 을 해 야 수정 이 session B 에서 유효 합 니 다.
 
4、seriabliable
이 단 계 는 트 랜 잭 션 격 리 안전성 이 가장 좋 지만 성능 이 가장 좋 지 않 습 니 다.이 단계 의 모든 작업 은 직렬 로 진행 되 기 때 문 입 니 다.하나의 조작 이 제출 되 지 않 았 고,다른 영향 을 받 은 조작 은 막 힌 상태 에 있 을 것 이다.
이러한 효 과 를 검증 하기 위해 저 희 는 먼저 환경 을 설정 합 니 다.구체 적 으로 session A 와 session B 에 다음 과 같이 설정 합 니 다.

session A 에서 임의의 필드 를 수정 하고 commt 작업 을 하지 않 았 습 니 다.이 때 session B 의 조회 동작 이 계속 막 힌 상태 에 있 음 을 발견 합 니 다.

이 는 직렬 화 격 리 효 과 를 설정 하 는 것 도 직렬 화 격 리 병행 능력 이 떨 어 지 는 이유 다.