MySQL 업무 의 기초 학습 및 소감 공유

사 무 는 논리 적 인 작업 으로 이 작업 의 각 단원 을 구성 합 니 다.모두 성공 하거나 모두 실패 하지 않 으 면 이 특성 은 바로 업무 입 니 다.다음은 MySQL 사무 학습 에서 의 소감 공유 입 니 다.
트 랜 잭 션 특성
1.원자 성(Atomicity):원자 성 이란 사 무 는 분리 할 수 없 는 업무 단위 로 업무 중의 조작 이 모두 발생 하거나 발생 하지 않 는 다 는 것 을 말한다. 
2.일치 성(Consistency):한 업무 에서 업무 전후 데이터 의 완전 성 은 반드시 일치 해 야 하 며 은행 이체,기차 구 매 를 상상 할 수 있다.
3.격 리 성(Isolation):여러 개의 사무,업무 의 격 리 성 은 여러 사용자 가 동시에 데이터 베 이 스 를 방문 할 때 한 사용자 의 사 무 는 다른 사용자 의 사무소 에 의 해 방 해 받 지 않 고 여러 개의 병행 사무 간 의 데 이 터 는 서로 격 리 되 어야 한 다 는 것 을 말한다.
4.지속 성(Durability):지속 성 이란 하나의 업무 가 제출 되면 데이터 베이스 에 대한 변 화 는 영구적 인 것 을 말 합 니 다.그 다음 에 데이터 베이스 가 고장 이 나 도 이에 영향 을 주지 말 아야 합 니 다.
이런 개념 을 쓰 는 것 은 좀 복잡 하 다!돌 면 돌아!어차피 내 가 정 한 것 도 아니 고 공식 적 인 거 야.설명 은 내 가 지 어 낸 거 야!!!
질문
만약 우리 가 격 리 성 문 제 를 고려 하지 않 는 다 면,사 무 는 세 가지 동시 방문 문제 가 존재 한다.
1.더러 운 읽 기:한 업무 에서 데 이 터 를 읽 을 때 다른 업무 가 제출 하지 않 은 데 이 터 를 읽 었 습 니 다. 
예 를 들 어 A 계 좌 는 B 계좌 에 1 원 을 이 체 했 지만 A 는 사 무 를 제출 하지 않 았 고 B 계 좌 는 더러 운 독 서 를 통 해 보 았 다.이때 B 는 A 가 돈 을 이미 이체 했다 고 생각 하지만 이때 A 계 좌 는 사 무 를 다시 굴 렸 다.사실 돈 은 B 에 게 돌려 주지 않 았 지만 B 자신 은 A 가 이미 돌아 간 줄 알 았 다.
코드 보기:

update account set money=money+1 where name='B';  --  A   B
update account set money=money -1 where name='A';

2.중복 읽 을 수 없습니다.한 업무 에서 두 번 읽 은 데이터 내용 이 일치 하지 않 습 니 다.이것 은 조회 할 때 시간 간격 이 있 고 데이터 가 다른 업무 에 의 해 수정 되 어 제출 되 었 기 때 문 입 니 다.그러면 문제 가 발생 할 수 있 습 니 다.
3.환 독/허 독:한 업무 에서 두 번 읽 는 데이터 의 양 이 일치 하지 않 습 니 다.
트 랜 잭 션 격 리 단계
위 에 세 가지 사무 병행 문 제 를 소개 했다!지금 데이터베이스 에서 제공 하 는 해결 방안 을 소개 합 니 다!
1.read uncommitted:제출 되 지 않 은 데 이 터 를 읽 습 니 다.이 최저 수준 이지 만 효율 이 가장 높 을 것 입 니 다.하지만 어떤 문제 도 해결 할 수 없습니다.
2.read committed:제출 한 데 이 터 를 읽 습 니 다:더러 운 읽 기 를 해결 할 수 있 습 니 다. 。
3.repeatable read:다시 읽 기:더러 운 읽 기와 중복 읽 기 를 해결 할 수 있 습 니 다.
4.serializable:직렬 화:더러 운 읽 기와 허 독 을 해결 할 수 있 고 효율 이 가장 낮 으 며 잠 금 표 에 해당 하 며 개발 에 서 는 일반적으로 사용 하지 않 습 니 다. 
위의"2"는 oracle 데이터베이스 기본 설정 이 고,"3"은 mysql 데이터베이스 기본 설정 입 니 다.
다음은 my sql 데이터베이스 가 위 에 있 는 각종 사무 격 리 단계 에서 의 프 리 젠 테 이 션 에 중심 을 두 고 설명 하 겠 습 니 다.
먼저 두 가지 문법 을 소개 합 니 다.
1.mysql 데이터베이스 기본 격 리 단계 보기:select@@txisolation
그림:

2.my sql 의 격 리 단 계 를 설정 합 니 다:set session transaction isolation level 트 랜 잭 션 의 격 리 단계
그림:

트 랜 잭 션 격 리 단계 데모
메모:만약 에 자신 이 모 의 하려 면 두 개의 my sql 클 라 이언 트 를 열 어야 합 니 다.즉,두 사용 자 를 모 의 하 는 것 입 니 다!
1.read uncommitted
그림:

나 는 문법 을 통 해 데이터베이스 의 사무 격 리 단 계 를 read uncommitted 로 바 꾸 었 다.
우선 계 정 표 가 한 장 있 습 니 다. 
창 1

 창 2

데이터베이스 시트 의 원시 데이터 Money 는 모두 5000 입 니 다.제 가 사 무 를 시작 한 후에 zhangsan 계 정 에 1000 을 증가 하고 이사 계 정 에서 1000 을 줄 였 습 니 다.그러나 제 사 무 는 아직 제출 되 지 않 았 습 니 다.그러나 제 가 데이터 베 이 스 를 다시 조회 할 때 데 이 터 는 이미 변화 가 생 겼 습 니 다.이것 이 바로 더러 운 읽 기와 중복 읽 을 수 없 는 읽 기 입 니 다!
환 독/허 독 은 숨 기지 않 겠 습 니 다.똑 같이 존재 합 니 다!
2.read committed
 그림:

나 는 데이터베이스 업무 격 리 성 을 read committed 로 바 꾸 었 다.
아니면 위의 그 시계?
창 1

 창 2
 
 
데이터베이스 테이블 zhangsan 계 정의 money 와 lisi 계 정의 money 가 모두 변 했 습 니 다.저 는 업 무 를 제출 하지 않 았 습 니 다.다른 창 사무 에서 조 회 를 열 었 을 때 더러 운 읽 기 가 나타 나 지 않 았 습 니 다.그러나 제 가 업 무 를 제출 할 때 다른 창의 업무 에서 다시 조회 하면 중복 읽 을 수 없 는 상황 이 발생 했 습 니 다.이렇게 하면 더러 운 읽 기 를 피 할 수 있 습 니 다.그러나 조회 할 때 이미 중복 읽 기와 환 독/허 독 이 나 타 났 습 니 다!
3.repeatable read
그림:

나 는 데이터베이스 업무 격 리 성 을 read committed 로 바 꾸 었 다.
아니면 위의 그 시계?
창 1

 창 2

나 는 두 창 에서 모두 사 무 를 열 었 다.창 이 데이터 조작 을 한 후에 사 무 를 제출 했다.창 2 의 업무 가 열 린 상황 에서 나 는 조회 하 러 갔다.방금 창 1 의 데이터 조작 기록 을 조회 하지 못 해서 더러 운 읽 기와 중복 읽 을 수 없 는 것 을 피 했다.
 어떤 사람 은 허 독/환 독 도 피 했다 고 하지만 사실은 없다.
 그림 보기:

제 가 lisi 계 정 을 조작 할 때 데 이 터 는 변 경 된 것 일 뿐 입 니 다.그러나 제 가 wangwu 계 정 을 수정 할 때 wangwu,계 정의 데 이 터 를 조회 하 러 갔 습 니 다.그러나 사실은 제 가 조작 하지 않 기 전에 wangwu 계 정의 데 이 터 는 조회 할 수 없습니다.이것 이 바로 환 독/허 독!
환 독/허 독 을 이해 하지 못 하면 이 노 DB 를 찾 아 보 세 요.
4.serializable
저 는 시범 을 보이 지 않 겠 습 니 다.개발 은 권장 하지 않 고 효율 도 느 리 지만 모든 문 제 는 피 할 수 있 습 니 다!!
총괄 하 다 
트 랜 잭 션 격 리 단계 의 성능:
read uncommitted>read committed>repeatable read>serialazable
트 랜 잭 션 격 리 단계 의 안전성:
read uncommittedmysql 사무 제어:
트 랜 잭 션 시작:start transaction;
제출:commt;
스크롤 백:rollback;