MySql 네 가지 사무 격 리 단 계 를 약술 하 다.
격 리 성 은 사실 생각 보다 복잡 하 다.SQL 표준 에서 네 가지 격 리 단 계 를 정 의 했 습 니 다.모든 사무 에서 수정 한 것,어떤 것 이 사무 내 와 사무 간 에 볼 수 있 고 어떤 것 이 보이 지 않 습 니까?낮은 등급 의 격 리 는 보통 더 높 은 병행 을 할 수 있 고 시스템 의 비용 도 더 낮다.
다음은 네 가지 격 리 단 계 를 간단하게 소개 한다.
1.READ UNCOMMITTED(읽 기 미 제출)
READ UNCOMMITTED 단계 에서 트 랜 잭 션 의 수정 은 제출 되 지 않 아 도 다른 트 랜 잭 션 에 대해 볼 수 있 습 니 다.업 무 는 제출 되 지 않 은 데 이 터 를 읽 을 수 있 습 니 다.이 를 더러 운 읽 기(Dirty Read)라 고도 합 니 다.이 단 계 는 많은 문 제 를 일 으 킬 수 있 습 니 다.성능 적 으로 READ UNCOMMITTED 는 다른 단계 보다 좋 지 않 지만 다른 단계 의 좋 은 점 이 많 지 않 습 니 다.정말 필요 한 이유 가 있 는 경 우 를 제외 하고 실제 응용 에 서 는 거의 사용 되 지 않 습 니 다.
(1)모든 사 무 는 제출 되 지 않 은 다른 업무 의 집행 결 과 를 볼 수 있다.
(2)본 격 리 단 계 는 실제 응용 에 사용 되 지 않 습 니 다.왜냐하면 성능 도 다른 단계 보다 별로 좋 지 않 기 때 문 입 니 다.
(3)이 단계 에서 발생 하 는 문 제 는 더러 운 읽 기(Dirty Read):제출 되 지 않 은 데 이 터 를 읽 었 다 는 것 이다.
# ，
set tx_isolation='READ-UNCOMMITTED';
select @@tx_isolation;
+------------------+
| @@tx_isolation |
+------------------+
| READ-UNCOMMITTED |
+------------------+# A：
start transaction;
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
+------+------+# B： ( )
B ，
start transaction;
update tx set num=10 where id=1;
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
+------+------+# A： A ?
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 10 | ---> ！ B
| 2 | 2 |
| 3 | 3 |
+------+------+# B： B ,
rollback;
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
+------+------+# A： A B
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 1 | ---> (A )， B ， ， ！
| 2 | 2 |
| 3 | 3 |
+------+------+대부분의 데이터베이스 시스템 의 기본 격 리 단 계 는 READ COMMITTED 입 니 다.MySQL 은 아 닙 니 다.READ COMMITTED 는 앞에서 언급 한 격 리 성에 대한 간단 한 정 의 를 만족 시 킵 니 다.하나의 업무 가 시 작 될 때 이미 제출 한 사무소 의 수정 만 볼 수 있 습 니 다.다시 말 하면,하나의 사 무 는 처음부터 제출 하기 전 까지,어떤 수정 도 다른 사무 에 대해 서 는 볼 수 없다.이 단 계 는 때때로 중복 읽 기 불가(nonrepeatableread)라 고도 부른다.같은 조 회 를 두 번 실행 하면 다른 결 과 를 얻 을 수 있 기 때문이다.
(1)이것 은 대부분의 데이터베이스 시스템 의 기본 격 리 단계 입 니 다.(MySQL 기본 값 은 아 닙 니 다.)
(2)격 리 의 간단 한 정 의 를 만족 시 켰 다.하나의 사 무 는 이미 제출 한 사무소 의 변화 만 볼 수 있다.
(3)이러한 격 리 단계 에서 발생 하 는 문 제 는 반복 적 으로 읽 을 수 없다 는 것 이다.(Nonrepeatable Read)반복 적 으로 읽 을 수 없다 는 것 은 우리 가 같은 업무 에서 똑 같은 selection 문 구 를 실행 할 때 서로 다른 결 과 를 볼 수 있다 는 것 을 의미한다.
이런 상황 을 초래 한 원인 은 다음 과 같다.
(1)교차 하 는 사무 에 새로운 commt 가 있어 데이터 의 변 화 를 초래 했다.
(2)하나의 데이터 베 이 스 를 여러 개의 인 스 턴 스 로 조작 할 때 같은 업무 의 다른 인 스 턴 스 는 이 인 스 턴 스 를 처리 하 는 동안 새로운 commt 가 있 을 수 있 습 니 다.
#
set tx_isolation='read-committed';
select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| READ-COMMITTED |
+----------------+# A：
start transaction;
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
+------+------+# B： ( )
，
start transaction;
update tx set num=10 where id=1;
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
+------+------+# A： A ?
select * from tx; --------------->
+------+------+ |
| id | num | |
+------+------+ |
| 1 | 1 |---> ！ |
| 2 | 2 | |
| 3 | 3 | |
+------+------+ |――> select ，
|
# B： B ? |
commit; |
|
# A: |
select * from tx; --------------->
+------+------+
| id | num |
+------+------+
| 1 | 10 |---> B ， A
| 2 | 2 |
| 3 | 3 |
+------+------+REPEATABLE READ 는 더러 운 독 서 를 해결 했다.이 단 계 는 같은 업무 에서 같은 기록 을 여러 번 읽 은 결과 가 일치 하 는 것 을 보증 합 니 다.그러나 이론 적 으로 중복 읽 기 격 리 단 계 는 또 다른 환 독(Phantom Read)문 제 를 해결 할 수 없다.환 독 이란 특정한 업무 가 특정한 범위 안의 기록 을 읽 을 때 다른 업무 가 이 범위 안에 새로운 기록 을 삽입 하 는 것 을 말한다.이전의 업무 가 이 범위 의 기록 을 다시 읽 을 때 환 행(Phantom Row)이 발생 한다.InnoDB 와 XtraDB 저장 엔진 이 여러 버 전의 병행 제어(MVCC,Multiversion Concurrency Control)를 통 해 환 독 문 제 를 해결 했다.
(1)MySQL 의 기본 트 랜 잭 션 격 리 단계 입 니 다.
(2)같은 업무 의 여러 인 스 턴 스 가 동시에 데 이 터 를 읽 을 때 같은 데이터 줄 을 볼 수 있 도록 확보 합 니 다.
(3)이 단계 에서 발생 할 수 있 는 문제-환 독(Phantom Read):사용자 가 특정한 범위 의 데이터 줄 을 읽 을 때 다른 사 무 는 이 범위 에 새 줄 을 삽입 합 니 다.사용자 가 이 범위 의 데이터 줄 을 다시 읽 을 때 새로운 환영 줄 이 있 습 니 다.
(4)InnoDB 와 Falcon 메모리 엔진 은 다 중 버 전 병행 제어(MVCC,Multiversion Concurrency Control)메커니즘 을 통 해 이 문 제 를 해결 했다.
# ，
set tx_isolation='repeatable-read';
select @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+# A：
start transaction;
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
+------+------+# B： ( )
B ，
start transaction;
update tx set num=10 where id=1;
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
+------+------+
commit;# A： B , A ？
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 1 | ---> ！( 2 ， 3 )
| 2 | 2 |
| 3 | 3 |
+------+------+# A： A ，
commit;
select * from tx;
+------+------+
| id | num |
+------+------+
| 1 | 10 |
| 2 | 2 |
| 3 | 3 |
+------+------+SERIALIZABLE 은 가장 높 은 격 리 단계 다.이 는 강제 적 인 직렬 실행 을 통 해 앞에서 말 한 환 독 문 제 를 피 할 수 있 습 니 다.쉽게 말 하면 SERIALIZABLE 은 읽 은 줄 마다 자 물 쇠 를 추가 하기 때문에 시간 초과 와 잠 금 경쟁 문 제 를 초래 할 수 있 습 니 다.실제 응용 에서 도 이 격 리 단 계 를 거의 사용 하지 않 고 데이터 의 일치 성 을 확보 해 야 하 며 동시 다발 성 이 없 는 상황 에서 만 이 단 계 를 사용 하 는 것 을 고려 할 수 있다.
(1)이것 은 가장 높 은 격 리 단계 이다.
(2)강제 적 인 사무 순 서 를 통 해 서로 충돌 하지 않 고 환 독 문 제 를 해결한다.쉽게 말 하면 읽 는 데이터 줄 마다 공유 자 물 쇠 를 추가 하 는 것 이다.
(3)이 단계 에서 대량의 시간 초과 현상 과 잠 금 경쟁 을 초래 할 수 있다.
#
set tx_isolation='serializable';
select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| SERIALIZABLE |
+----------------+# A：
start transaction;# B： A commit ，
start transaction;
insert tx values('4','4');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
update tx set num=10 where id=1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Redash를 사용할 때 몰랐던 SQL을 쓰는 법을 배웠습니다.최근 redash에서 sql을 쓸 기회가 많고, 이런 쓰는 방법이 있었는지와 sql에 대해 공부를 다시하고 있기 때문에 배운 것을 여기에 씁니다. Redash란? 월별로 데이터를 표시하고 싶습니다 주별로 데이터를 표...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
