MySQL InnoDB 가 사무 특성 을 어떻게 보장 하 는 지 에 대한 예시 상세 설명

머리말
만약 누군가가 당신 에 게"데이터베이스 사무 에는 어떤 특성 이 있 습 니까?"라 고 묻는다 면?당신 은 곧 원자 성,일치 성,격 리 성,지속 성 즉 ACID 특성 에 대답 할 수 있 습 니 다.그럼 이 노 DB 가 이런 업무 특성 을 어떻게 보장 하 는 지 아 세 요?이 글 을 알 면 그냥 넘 어가 볼 수 있 습 니 다(\#^.^\#)
먼저 결론 을 말 하 다.

redo log 로 그 를 다시 작성 하여 업무 의 지속 성 을 확보 합 니 다

undo log 스크롤 백 로그 보증 업무 의 원자 성

undo log+redo log 보증 업무 의 일치 성

자물쇠(공유,배타)는 업무 의 격 리 성 을 확보 하 는 데 사용 된다.

로그 다시 만 들 기 redo log
다시 만 들 기 로그 redo log 는 두 부분 으로 나 뉜 다.일 부 는 메모리 에 있 는 다시 만 들 기 로그 버퍼(redo log buffer)로 잃 어 버 리 기 쉽다.두 부분 은 로그 파일(redo log file)을 다시 만 드 는 것 으로 오래 간다.InnoDB 는 Force Log at Commit 메커니즘 을 통 해 지속 성 을 실현 합 니 다.commt 에 서 는 로그 파일 을 다시 만 들 때 까지 모든 로 그 를 기록 해 야 합 니 다.commt 작업 이 완료 되 어야 완 료 됩 니 다.
InnoDB 는 로그 버퍼 를 다시 만 드 는 내용 을 다음 과 같이 기록 합 니 다.

master thread 는 로그 버퍼 를 다시 만 들 때 로그 파일 로 리 셋 합 니 다.

모든 사무 제출 시

로그 버퍼 의 남 은 공간 이 1/2 보다 적 을 때

로그 파일 을 다시 만 들 기 위해 서 는 로그 버퍼 를 다시 만 들 때마다 InnoDB 저장 엔진 이 fsync(브러시)를 호출 해 야 합 니 다.그렇다 고 절대 그런 건 아니 야.사용 자 는 innodb 수정 을 통 해flush_log_at_trx_commoit 매개 변 수 는 로 그 를 다시 디스크 에 새로 고침 하 는 정책 을 제어 합 니 다.이것 은 대량의 트 랜 잭 션 을 제출 할 때 최적화 할 수 있 습 니 다.

1 매개 변수 기본 값 은 트 랜 잭 션 제출 시 fsync 작업 을 한 번 호출 해 야 한 다 는 것 을 나타 낸다.

0 은 트 랜 잭 션 을 제출 할 때 로그 캐 시 를 다시 만 드 는 것 은 로그 파일 을 다시 만 드 는 것 이 아니 라 Master Thread 간격 에 따라 fsync 작업 을 합 니 다.

2 는 트 랜 잭 션 을 제출 할 때 로 그 를 다시 작성 하고 로그 파일 을 다시 작성 하 는 것 을 표시 하지만 파일 시스템 의 캐 시 에 만 기록 하고 fsync 작업 을 하지 않 습 니 다.
fsync 의 효율 은 디스크 의 성능 에 달 려 있 기 때문에 디스크 의 성능 은 트 랜 잭 션 제출 의 성능,즉 데이터 뱅 크 의 성능 을 결정 합 니 다.그래서 만약 에 누군가가 Mysql 데이터 베 이 스 를 최적화 하 는 방법 을 물 었 을 때 하드웨어 라 는 것 을 잊 지 말고 하 드 디스크 설정 을 향상 시 키 고 SSD 고체 하 드 디스크 로 바 꾸 도록 하 세 요.
로 그 를 다시 만 드 는 것 은 512 바이트 로 저 장 됩 니 다.다시 만 드 는 로그 블록 이 라 고 합 니 다.디스크 섹 터 크기 와 일치 합 니 다.로 그 를 다시 만 드 는 기록 은 원자 성 을 확보 할 수 있 고 doublewrite 기술 이 필요 하지 않 습 니 다.그것 은 다음 과 같은 세 가지 특성 이 있다.

재 작성 일 지 는 InnoDB 층 에서 발생 한

입 니 다.

로 그 를 다시 만 드 는 것 은 물리 적 형식 로그 이 고 각 페이지 의 수정

을 기록 합 니 다.

재 작성 로 그 는 업무 진행 중 에 계속 기록 되 고 순서대로 기록 되 었 습 니 다.

스크롤 백 로그 undo log
업무 의 원자 성 을 만족 시 키 기 위해 서 는 모든 데 이 터 를 조작 하기 전에 데 이 터 를 한 곳 에 백업 한 다음 에 데 이 터 를 수정 합 니 다.오류 가 발생 했 거나 사용자 가 ROLLBACK 문 구 를 실 행 했 을 경우 시스템 은 Undo Log 의 백업 을 이용 하여 데 이 터 를 업무 시작 전 상태 로 복원 할 수 있 습 니 다.
undo log 는 다 중 버 전 병행 제어(MVCC)를 실현 하여 업무 의 격 리 성 을 보조 합 니 다.
스크롤 로 그 는 로 그 를 다시 만 드 는 것 과 다 릅 니 다.논리 로그 입 니 다.데이터 베 이 스 를 수정 하 는 것 은 모두 논리 적 으로 취소 되 었 습 니 다.일이 다시 굴 러 갈 때,그것 은 실제로 이전 과 반대 되 는 일 을 하 는 것 이다.모든 INSERT 에 대해 InnoDB 메모리 엔진 은 하나의 DELETE 를 완성 합 니 다.모든 UPDATE 에 대해 InnoDB 메모리 엔진 은 상 반 된 UPDATE 를 실행 합 니 다.
트 랜 잭 션 을 제출 한 후 바로 undo log 를 삭제 할 수 없습니다.이 는 undo log 를 통 해 이전 버 전 을 기록 해 야 할 다른 트 랜 잭 션 이 있 을 수 있 기 때 문 입 니 다.따라서 트 랜 잭 션 을 제출 할 때 undo log 를 하나의 링크 에 넣 고 undo log 를 삭제 할 수 있 습 니까?작업 에 따라 다음 과 같은 2 가지 상황 으로 나 눌 수 있 습 니까?

Insert undo log:insert 작업 의 기록 은 사무 자체 만 볼 수 있 고 다른 사무 에 대해 서 는 볼 수 없 기 때문에 이 undo log 는 사무 제출 후 직접 삭제 할 수 있 습 니 다.Purge 작업 이 필요 없습니다.

update undo log:delete 와 update 작업 에 대한 undo log 를 기록 합 니 다.이 undo log 는 MVCC 메커니즘 을 제공 해 야 할 수도 있 기 때문에 사무 제출 시 삭제 할 수 없습니다.제출 할 때 undo log 링크 를 넣 고 Purge 스 레 드 가 마지막 으로 삭 제 될 때 까지 기 다 립 니 다.

자물쇠.
사무의 격 리 성의 실현 원 리 는 바로 자물쇠 이기 때문에 격 리 성도 병발 제어,자물쇠 등 이 라 고 할 수 있다.트 랜 잭 션 의 격 리 성 은 모든 읽 기와 쓰기 대상 이 다른 트 랜 잭 션 의 작업 대상 을 서로 분리 할 수 있 도록 요구한다.또한,예 를 들 어 버퍼 에 있 는 LRU 목록 을 조작 하고 삭제 하 며 LRU 목록 에 있 는 요 소 를 추가,이동 하 며 일치 성 을 확보 하기 위해 잠 금 의 개입 을 해 야 합 니 다.
자물쇠 의 종류
InnoDB 는 주로 2 가지 자물쇠 가 있 습 니 다.줄 자물쇠,의향 자물쇠 입 니 다.
줄 잠 금:

공유 자물쇠(자물쇠 읽 기 S),한 줄 의 데 이 터 를 읽 을 수 있 습 니 다.트 랜 잭 션 은 한 줄 에 기 록 된 공유 S 자 물 쇠 를 가 져 와 야 이 줄 을 읽 고 다른 트 랜 잭 션 이 X 자 물 쇠 를 추가 하 는 것 을 막 을 수 있 습 니 다.공유 자물쇠 의 목적 은 읽 기와 읽 기 병행 을 향상 시 키 는 것 이다.

줄 의 잠 금(잠 금 X 쓰기)은 한 줄 의 데 이 터 를 삭제 하거나 한 줄 의 데 이 터 를 업데이트 할 수 있 습 니 다.한 줄 에 기 록 된 열 X 자 물 쇠 를 가 져 와 야 이 줄 을 수정 하거나 삭제 할 수 있 습 니 다.배타 적 자물쇠 의 목적 은 데이터 의 일치 성 을 확보 하기 위 한 것 이다.

줄 잠 금 에는 S 와 S 가 호 환 되 는 것 을 제외 하고 모두 호 환 되 지 않 습 니 다.
의향 잠 금:

의향 공유 잠 금(읽 기 잠 금 IS),한 장의 표 의 몇 줄 데이터 공유 잠 금 을 가 져 오 려 면 데이터 줄 에 공유 잠 금 을 추가 하기 전에 이 표 의 IS 잠 금 을 가 져 와 야 합 니 다.

의향 배타 자물쇠(자물쇠 IX 쓰기),테이블 에 있 는 몇 줄 의 데 이 터 를 가 져 오 려 면 데이터 줄 에 배타 자 물 쇠 를 추가 하기 전에 이 테이블 의 IX 자 물 쇠 를 가 져 와 야 합 니 다.

의향 자 물 쇠 를 설명해 주세요.
The main purpose of IX and IS locks is to show that someone is locking a row, or going to lock a row in the table.
의향 잠 금 의 주요 용 도 는 특정한 업무 가 한 줄 을 잠 그 거나 한 줄 의 데 이 터 를 잠 그 는 것 을 표현 하기 위 한 것 이다.e.g:사무 A 가 한 줄 의 기록 r 에 X 자 물 쇠 를 채 우려 면 InnoDB 는 신청서 의 IX 자 물 쇠 를 먼저 채 우 고 기록 r 의 X 자 물 쇠 를 잠 글 것 입 니 다.트 랜 잭 션 A 가 완료 되 기 전에 트 랜 잭 션 B 는 전체 표 작업 을 하려 고 합 니 다.이때 표 단계 의 IX 에서 트 랜 잭 션 B 에 게 표 에서 모든 줄 에 자물쇠 가 있 는 지 판단 하지 않 고 기 다 려 야 한다 고 알려 줍 니 다.의향 배열 자물쇠 의 존재 가 치 는 InnoDB 가 자물쇠 에 대한 포 지 셔 닝 과 처리 성능 을 절약 하 는 데 있다.또한 전체 표 스 캔 을 제외 하고 의향 자 물 쇠 는 막 히 지 않 음 을 주의 하 세 요.
잠 금 알고리즘
InnoDB 는 세 가지 줄 잠 금 알고리즘 이 있 습 니 다.

Record Lock:단일 줄 기록 의 자물쇠

Gap Lock:간극 잠 금,기록 자체

이 아 닌 범 위 를 잠 금 합 니 다.

Next-Key Lock:Gap Lock 과 Record Lock 을 결합 하여 하나의 범 위 를 잠 그 고 기록 자 체 를 잠 금 합 니 다.주요 해결 문 제 는 REPEATABLE READ 격 리 단계 에서 의 환 독 이다.글 을 참고 하여 사무 격 리 등급 에 관 한 지식 을 알 수 있다.

여기 서 주로 next-Key Lock 에 대해 이야기 합 니 다.next-key Lock 을 이용 하여 잠 긴 것 은 하나의 값 이 아니 라 하나의 범위 입 니 다.그의 목적 은 여러 개의 사무 가 기록 을 같은 범위 에 삽입 하 는 것 을 막 기 위해 서 입 니 다.
유일한 색인 으로 가면 다음-Key Lock 은 범위 가 아 닌 색인 자체 만 잠 그 는 Record Lock 으로 강 등 됩 니 다.즉,Next-Key Lock 의 사전 조건 은 트 랜 잭 션 격 리 단계 가 RR 이 고 조회 한 색인 이 유일한 색인,홈 키 색인 이 아 닌 것 이다.
다음은 예 를 들 어 자세히 말씀 드 리 겠 습 니 다.
먼저 표를 만 듭 니 다.

CREATE TABLE T (id int ,f_id int,PRIMARY KEY (id), KEY(f_id)) ENGINE=InnoDB DEFAULT CHARSET=utf8
insert into T SELECT 1,1;
insert into T SELECT 3,1;
insert into T SELECT 5,3;
insert into T SELECT 7,6;
insert into T SELECT 10,8;

사무 A 는 다음 문장 을 실행 합 니 다:

SELECT * FROM T WHERE f_id = 3 FOR UPDATE

이 때 SQL 문 구 는 유일한 색인 이 아니 므 로 Next-Key Locking 을 사용 하여 자 물 쇠 를 추가 하고 2 개의 색인 이 있 으 며 각각 잠 금 이 필요 합 니 다.
집합 색인 에 대해 서 는 id 가 5 와 같은 색인 에 Record Lock 만 추가 합 니 다.반면 보조 색인 에 대해 서 는 다음-Key Lock 을 더 해 범위(1,3)를 잠 그 고 있 으 며,특히 이 노 DB 저장 엔진 은 보조 색인 다음 키 에 갭 Lock,즉 범위(3.6)의 자 물 쇠 를 더 할 수 있다 는 점 에 주목 해 야 한다.
그래서 새 session 에서 다음 문 구 를 실행 하면 [Err] 1205 - Lock wait timeout exceeded; try restarting transaction 을 잘못 보고 할 수 있 습 니 다.

select * from T where id = 5 lock in share MODE --     ，    A   id=5     X ，      
INSERT INTO T SELECT 4,2 --     ，       2， （1,3）    ，    
INSERT INTO T SELECT 6,5 --     ，gap    （3,6）   ，    

이때 상상 해 보 세 요.사무 A 가 f 를 잠 갔 어 요.id=5 의 기록,정상적으로 gap lock,잠 금(5,6)이 있 습 니 다.그러면(5,6)의 gap 자물쇠 가 없 으 면 사용 자 는 색인 f 를 삽입 할 수 있 습 니 다.id 가 5 인 기록 은 사무 A 가 다시 조회 하면 서로 다른 기록 을 되 돌려 주 고 환 독 의 발생 을 초래 합 니 다.
마찬가지 로 만약 에 우리 업무 A 가 select * from T where f_id = 10 FOR UPDATE 을 집행 하면 표 에서 데 이 터 를 찾 을 수 없 지만 Next-Key Lock 을 바탕 으로 잠 길 것 이다(8,+표시).우 리 는 INSERT INTO T SELECT 6,11 을 집행 하면 성공 적 으로 삽입 할 수 없 기 때문에 근본적으로 환 독 문 제 를 해결 했다.
총결산
이상 은 이 글 의 모든 내용 입 니 다.본 고의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 참고 학습 가 치 를 가지 기 를 바 랍 니 다.여러분 의 저희 에 대한 지지 에 감 사 드 립 니 다.