Mysql 더러 운 페이지 flush 및 수축 표 공간 원리 분석

더러 운 mysql
WAL 메커니즘 으로 인해 InnoDB 는 문 구 를 업데이트 할 때 로 그 를 쓰 는 디스크 작업 을 만 들 었 습 니 다.바로 redo log 입 니 다.메모리 에 redo log 를 쓴 후에 클 라 이언 트 에 게 되 돌아 갑 니 다.즉,업데이트 에 성 공 했 습 니 다.
메모리 에 있 는 데 이 터 를 디스크 에 기록 하 는 과정 에서 용 어 는 flush 입 니 다.flush 전에 실제 데이터 와 데이터 베이스 에 있 는 데 이 터 는 일치 하지 않 습 니 다.redo log 를 바탕 으로 아직 기록 되 지 않 았 기 때 문 입 니 다.데이터 베 이 스 는 오래된 것 입 니 다.메모리 데이터 페이지 와 디스크 데이터 페이지 의 내용 이 다 를 때 이 메모리 페이지 를 더러 운 페이지 라 고 부 르 고 메모리 가 기록 되면 일치 합 니 다.깨끗 한 페이지 라 고 부 릅 니 다.
my sql 이 가끔 운행 속도 가 느 리 면 더러 운 페이지 를 닦 고 있 을 수 있 습 니 다.데이터베이스 flush 를 유발 하 는 과정

redo log 가 가득 차 서 시스템 이 모든 업데이트 작업 을 중단 하고 checkpoint 를 앞으로 추진 하 며 공간 을 비 워 계속 씁 니 다

4.567917.시스템 메모리 가 부족 하고 새로운 메모리 페이지 가 필요 하지 않 으 면 데이터 페이지 를 도태 시 키 고 다른 데이터 페이지 에 남 겨 서 사용 합 니 다.더러 운 페이지 를 도태 시 키 면 디스크 에 먼저 기록 합 니 다my sql 한가 할 때mysql 을 정상적으로 닫 았 을 때

첫 번 째 상황 에서 redo log 가 가득 찼 습 니 다.이런 상황 은 innodb 가 피해 야 합 니 다.전체 시스템 이 더 이상 업데이트 되 지 않 기 때문에 받 아들 일 수 없습니다

두 번 째 상황 은 메모리 가 가득 차 서 디스크 에 먼저 써 야 합 니 다.innodb 는 버퍼 로 메모 리 를 관리 하고 세 가지 상태 가 있 습 니 다

4.567917.아직 사용 하지 않 은 메모리 페이지4.567917.사용 하고 깨끗 한 페이지 입 니 다.4.567918.
4.567917.사용 하고 더러 운 페이지(탈락 할 때 디스크 에 기록 해 야 함)그래서 우 리 는 때때로 데이터 베 이 스 를 사용 하면 데이터 뱅 크 의 성능 이 갑자기 떨 어 지 는 것 을 발견 할 수 있 는데,아마도 더러 운 페이지 를 처리 하 는 것 일 것 이다.
더러 운 페이지 제어 전략

Innodb_io_capacity 매개 변수,이 매개 변 수 는 innodb 의 디스크 io 능력 을 알려 줍 니 다.(공식 계산 이 있다)

4.567917.innodb 브러시 의 주요 두 가지 요소:더러 운 페이지 비율 과 redo log 의 쓰기 속도

innodb_max_derty_pages_pct 는 더러 운 페이지 비율 상한 선,기본 값 75%,Innodb 조정io_capacity 매개 변수 값,더러 운 페이지 비율 이 75%수축 표 공간 을 초과 하지 않도록 합 니 다

장면 예:데이터 베 이 스 는 공간 이 너무 커서 가장 큰 시 계 를 절반 의 데 이 터 를 삭 제 했 지만 표 의 크기 는 변 하지 않 았 다.
데이터 삭제 프로 세 스

R4 를 삭제 하려 면 InnoDB 엔진 은 R4 라 는 기록 만 삭제 로 표시 하고,이후 ID 300~600 사이 의 기록 을 하나 더 섞 으 면 이 위 치 를 재 활용 하지만 디스크 파일 의 크기 는 줄 어 들 지 않 는 다.
데이터 페이지 의 모든 기록 을 삭제 하면 이 데이터 페이지 는 재 활용 할 수 있다.
메모:데이터 페이지 의 재 활용 과 기록 의 재 활용 은 다 릅 니 다.

예 를 들 어 R4 라 는 기록 이 삭제 되 었 습 니 다.만약 에 ID 가 400 인 줄 을 삽입 하면 이 공간 을 직접 재 활용 하지만 ID 가 800 인 줄 을 삽입 하면 이 위 치 를 재 활용 할 수 없습니다

그러나 전체 데이터 페이지 페이지 페이지 페이지 A 의 모든 기록 이 삭 제 된 후에 페이지 A 는 재 활용 가능 한 것 으로 표 시 됩 니 다.만약 에 ID=50 의 기록 을 삽입 할 때 새로운 데이터 페이지 를 사용 해 야 할 때 PageA 는 부담 할 수 있 습 니 다

4.567917.만약 에 우리 가 delete 명령 으로 전체 표 데 이 터 를 삭제 하면 모든 데이터 페이지 는 재 활용 가능 한 것 으로 표시 되 지만 디스크 에 서 는 파일 이 작 아 지지 않 습 니 다데이터 프로 세 스 삽입
만약 데이터 가 색인 순서에 따라 삽입 된다 면 색인 은 치밀 하지만 무 작위 로 삽입 된다 면 색인 의 데이터 페이지 를 나 눌 수 있다.

만약 pagea 가 가득 찼 다 면,한 줄 의 데 이 터 를 삽입 하면 어떻게 됩 니까?A 가 가득 차 서 하나의 id 가 550 인 데 이 터 를 삽입 할 때 새로운 페이지 pageB 를 신청 하여 데 이 터 를 저장 합 니 다.분 단 이 완료 되면 pageA 의 끝 에 구멍 이 남 습 니 다.
색인 에 있 는 값 을 업데이트 하 는 것 도 오래된 값 을 삭제 하고 새 값 을 삽입 하면 구멍 이 생 길 수 있 습 니 다.
공간 을 수축 하 다
표 A 와 같은 구조의 표 B 를 새로 만 들 고 메 인 키 ID 가 증가 하 는 순서에 따라 데 이 터 를 한 줄 한 줄 씩 A 에서 읽 어서 표 B 에 삽입 합 니 다.표 B 에 구멍 이 없고 데이터 페이지 의 이 용 률 도 높 습 니 다.만약 에 우리 가 표 B 를 임시 표 로 하면 데 이 터 를 표 A 에서 B 로 가 져 오 는 작업 이 완 료 된 후에 B 로 A 를 교체 하면 효과 적 으로 A 를 수축 하 는 역할 을 합 니 다.

전체 DDL 과정 에서 표 A 는 업데이트 할 수 없 기 때문에 이 DDL 은 온라인 이 아 닙 니 다.5.6 이후 버 전에 서 절차 가 변경 되 었 습 니 다.
임시 파일 을 만 들 고 A 의 모든 데이터 페이지 를 검색 합 니 다.
데이터 페이지 의 A 기록 으로 B+트 리 를 생 성하 여 임시 파일 에 저장 합 니 다.
A 에 대한 모든 작업 을 로그 파일 에 기록 합 니 다.
임시 파일 생 성 후 로그 파일 작업 을 임시 파일 에 적용 하여 논리 적 데이터 에서 표 A 와 같은 데이터 파일 을 얻 습 니 다.
표 A 의 데이터 파일 을 임시 파일 로 대체 합 니 다.
도시

그림 3 과정 과 다른 점 은 로그 파일 기록 과 재생 작업 이라는 기능 이 존재 하기 때문에 이 방안 은 표를 재 구축 하 는 과정 에서 표 A 를 추가 삭제 하고 수정 할 수 있 습 니 다.
alter table A engine=InnoDB 명령 을 사용 하여 표를 다시 만 듭 니 다.MySQL 5.5 버 전에 서 이 명령 의 실행 절 차 는 앞에서 설명 한 것 과 차이 가 많 지 않 습 니 다.이 임시 표 B 는 당신 이 직접 만 들 필요 가 없습니다.MySQL 은 자동 으로 데 이 터 를 저장 하고 표 이름 을 교환 하 며 오래된 표를 삭제 하 는 작업 을 수행 합 니 다.
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.