MySQL 의 얕 은 입 심 출 페이지 원리 에 대하 여 말씀 드 리 겠 습 니 다.

개관
우리 가 MySQL 에 삽입 한 데 이 터 는 결국 페이지 에 존재 합 니 다.InnoDB 의 디자인 에서 페이지 와 페이지 사 이 는 하나의 양 방향 링크 를 통 해 연결된다.
페이지 에 저 장 된 한 줄 한 줄 의 데 이 터 는 단일 링크 를 통 해 연결 된다.

위의 그림User Records의 구역 은 줄 데 이 터 를 저장 하 는 데 쓰 인 다.그럼 이 노 DB 는 왜 이렇게 디자인 했 어 요?만약 에 우리 가 페이지 라 는 개념 이 없다 고 가정 하면 우리 가 조회 할 때 수천 명의 데 이 터 는 어떻게 신속하게 결 과 를 조회 해 야 합 니까?모두 가 알다 시 피 MySQL 의 성능 은 좋 은 데 페이지 가 없 으 면 우 리 는 하나하나 데 이 터 를 옮 겨 다 닐 수 밖 에 없다.
그 페이지 는 어떻게 빠 른 조 회 를 합 니까?현재 페이지 에 서 는User Records의 각 기록 을 연결 하 는 단일 체인 표를 통 해 옮 겨 다 닐 수 있 으 며,현재 페이지 에서 찾 지 못 하면 다음 페이지 지침 을 통 해 다음 페이지 로 빠르게 넘 어가 조회 할 수 있 습 니 다.
2.인 피 엠 과 슈 프 림
누 군 가 는 당신 이User Records에서 역대로 해결 한 것 이 아니 라 데 이 터 를 간단하게 그룹 으로 나 누 었 을 뿐 이 라 고 말 할 수 있 습 니 다.만약 나의 데이터 가 현재 이 페이지 에 전혀 없다 면,나 는 설마 이전의 페이지 의 모든 데 이 터 를 다 옮 겨 다 녀 야 합 니까?효율 이 너무 낮 아 요.
물론 MySQL 도 이 문 제 를 고려 했 기 때문에 실제 페이지 에The Infimum and Supremum Records라 는 구역 이 존재 하 는데 현재 페이지 에서 가장 크 고 가장 작은 기록 을 대표 한다.
Infimum Record와Supremum Record가 있 습 니 다.현재 조 회 는 한 페이지 의User Records를 모두 옮 겨 다 닐 필요 가 없습니다.이 두 기록 과 조 회 를 기다 리 는 목표 기록 을 비교 해 야 합 니 다.예 를 들 어 내 가 조회 하고 자 하 는 데이터id = 101는 현재 페이지 에 없 는 것 이 분명 하 다.다음 페이지 포인 터 를 통 해 다음 페이지 로 넘 어가 검색 할 수 있다.
3.페이지 디렉토리 사용
누군가가 또 말 할 수 있 을 것 이다.너 도 이User Records안에 모두 단일 체인 시계 가 있 지 않 니?설령 내 가 찾 는 데이터 가 현재 페이지 에 있다 는 것 을 안다 하 더 라 도,그 최 악의 상황 에 서 는 내 가 찾 는 데 이 터 를 하나씩 100 번 씩 옮 겨 다 녀 야만 찾 을 수 있 지 않 겠 는가?너 는 이것 도 효율 이 높다 고 하 니?
이것 은 확실히 문제 이지 만 MySQL 이 이미 고려 한 문제 에 불과 하 다.좋아,하나씩 옮 겨 다 니 면 확실히 효율 이 낮 아.이 문 제 를 해결 하기 위해 MySQL 은 페이지 에 또 다른 영역Page Directory을 추가 했다.

말 그대로Page Directory는 하나의 목록 으로 그 안에 여러 개의 슬롯(Slots)이 있 고 모든 슬롯 은 하나의User Records중의 기록 을 가리킨다.몇 개의 데이터 마다 슬롯 을 만 드 는 것 을 볼 수 있 습 니 다.사실 제 그림 에서 제 시 된 데 이 터 는 매우 엄격하게 설정 한 것 입 니 다.전체 페이지 에서 6 개의 데이터 마다 Slot 가 있 습 니 다.
Page Directory 의 디자인 은 다른 데이터 구 조 를 떠 올 리 게 하 는 지 모 르 겠 지만,여 기 는 색인 만 추상 화 했 을 뿐이다.
MySQL 은 데 이 터 를 새로 추가 할 때 해당 하 는 Slot 를 만 들 고Page Directory이 있 으 면 한 페이지 의 데 이 터 를 대충 2 점 으로 찾 을 수 있 습 니 다.왜 대략적인 지 에 대해 서 는Page Directory에서 완전한 데이터 가 아니 기 때문에 2 분 에 찾 은 결 과 는 대략적인 위치 일 수 밖 에 없다.이 대략적인 위 치 를 찾 은 후에User Records로 돌아 가 계속 매 칭 해 야 한다.
그러나 이런 효율 은 우리 가 처음 이야기 한 원본 버 전보 다 훨씬 높 아 졌 다.

진면목
만약 에 제 가 시작 하면 페이지 의 각종 구성 부분,각종 개념 을 직접 던 져 서 먼저 제 가 받 아들 일 수 없어 서 딱딱 해 보 입 니 다.그 다음으로 페이지 에 익숙 하지 않 은 사람 은 페이지 가 왜 이렇게 디자인 되 었 는 지 이해 하지 못 할 것 이다.그래서 저 는 데 이 터 를 조회 하 는 사고방식 에 따라 페이지 의 대체적인 모습 을 여러분 께 보 여 드 렸 습 니 다.
실제로 페이지 에는 다른 필드 도 많이 저장 되 어 있 고 다른 지역 도 있 지만 이런 것들 은 우리 가 페이지 에 대한 이해 에 영향 을 주지 않 습 니 다.그래서 페이지 에 대해 비교적 뚜렷 한 인식 을 가 진 후에 우 리 는 실제 페이지 가 어떻게 생 겼 는 지 볼 수 있다.

위의 그림 은 바로 페이지 의 실제 구성 이다.우리 가 전에 언급 한 것 을 제외 하고 이전에 이야기 하지 않 았 던 것 도 많다.예 를 들 어File Header,Page Header,Free Space,File Tailer등 이다.우리 하나씩 보 자.
4.1、File Header
사실File Header윗글 에서 이미 이 야 기 를 나 누 었 는데,단지 이 이름 을 부 르 지 않 을 뿐이다.위 에서 언급 한 이전 페이지 의 지침 과 다음 페이지 의 지침 은 사실File Header에 속 하 는데 그 밖 에 다른 데이터 도 많다.

사실 나 는 한 무더기 의 매개 변 수 를 열거 하 는 것 을 비교적 거부 하 는데,너 에 게 이 크기 가 얼마 인지,그것 을 무엇 에 쓰 는 지 알려 주 겠 다.우리 가 상세 하 게 페이지 를 알 아야 하 는 데 있어 서 사실은 잠시 두 가지 만 알 면 충분 하 다.각각:

FIL_PAGE_PREV

FIL_PAGE_NEXT

이 두 변 수 는 바로 앞에서 언급 한 이전 페이지 의 지침 과 다음 페이지 의 지침 이다.지침 이 라 고 하 는 것 은 여러분 의 이 해 를 편리 하 게 하기 위해 서 이다.사실은 디스크 에 있 는 페이지 의 오프셋 이다.
4.2、Page HeaderFile Header보다Page Header의 데 이 터 는 우리 에 게 더욱 익숙 해 졌 다.나 는 여기에 그림 을 한 장 그 려 서 안의 내용 을 상세 하 게 열거 했다.

여기 서 모두 열거 한 것 은 이러한 매개 변수의 의미 와 왜 매개 변 수 를 설정 해 야 하 는 지 알 기 때문에 우리 가 페이지 의 원리 와 구 조 를 이해 하 는 데 도움 을 주 고 구체 적 으로 그림 을 보고 말 하면 된다.
여기 서도 토로 하고 싶 습 니 다.너무 많은 블 로그 들 이 너무 경직 되 어 있 습 니 다.예 를 들 어 매개 변수PAGE_HEAP_TOP,여기HEAP의 많은 블 로 그 는 바로 더미 라 고 부 릅 니 다.이것 은 네가Init에 주석 을 쓰 는 것 을 초기 화 라 고 하 는 것 과 마찬가지 로 차라리 쓰 지 않 는 것 이 낫다.실제로 연 구 를 해 보면 이곳 의 더 미 는 사실상 User Records 를 말 하 는 것 임 을 알 수 있 을 것 이다.
안에 두 개의 매개 변 수 는 약간 혼 란 스 러 울 수 있 습 니 다.각각PAGE_N_HEAP과PAGE_N_RECS는 현재User Records에 기 록 된 수량 입 니 다.유일한 차이 점 은PAGE_N_HEAP에 삭 제 된 기록 이 포함 되 어 있 고PAGE_N_RECS에 서 는 실제로 우리 가 조회 할 수 있 는 모든 데 이 터 를 포함 하고 있 습 니 다.
4.3、Infimum & Supremum Records
앞에서 언급 한 바 와 같이Infimum & Supremum Records현재 페이지 의 최대 최소 기록 을 기록 할 것 이다.실제로 정확 하지 않 고 더 정확 한 묘 사 는 최소 기록 과 최대 기록 의 개방 구간 이다.실제Infimum Records는 현재 페이지 의 최소 치보다 작 고Supremum Records는 현재 페이지 의 최대 치보다 크기 때문이다.
4.4、User RecordsUser Records우리 가 평소에 가장 많이 접 한 부분 이 라 고 할 수 있다.왜냐하면 우리 의 데 이 터 는 결국 여기에 있 기 때문이다.페이지 가 초기 화 되면User Records에는 데이터 가 없고 시스템 이 작 동 하면 서 데이터 가 생 겨User Records의 데이터 가 계속 팽창 하고 해당Free Space공간 이 점점 작 아 집 니 다.User Records의 개념 에 대해 서 는 이미 이 야 기 를 나 누 었 다.여기 서 내 가 매우 중요 하 게 생각 하 는 것 만 이야기 하 는데,그것 이 바로 순서 이다.
클 러 스 터 색인 에서 키 는 실제로Primary Key순서에 따라 배열 된다 는 것 을 잘 알 고 있다.그럼User Records에서 도 이 럴 까요?우리 가 새로운 데 이 터 를User Records에 삽입 할 때 도Primary Key의 순서에 따라 기 존의 데 이 터 를 다시 정렬 할 수 있 습 니까?
정 답 은 아니다.왜냐하면 이렇게 하면 MySQL 처리 의 효율 을 낮 출 수 있 기 때문이다.User Records중의 데 이 터 는 단일 체인 시계 포인터 의 가리 키 는 방향 으로 보장 된다.즉,줄 데이터 가 실제 디스크 에서 의 표현 은 삽입 순서에 따라 줄 을 서 는 것 이 고 먼저 도착 한 데 이 터 는 앞 에 있 으 며 나중에 데 이 터 는 뒤에 있다.다만User Records중의 줄 데이터 간 의 단일 체인 표를 통 해Primary Key에 따라 배열 하 는 순 서 를 형성 했다.
그림 으로 표시 하면 대략 다음 과 같다.

4.5、Free Space
이 사실은 변 형 된 것 은 다른 모듈 에서 토론 되 었 다.처음에User Records는 완전히 비어 있 었 고 새로운 데이터 가 들 어 왔 을 때Free Space에서 공간 을 신청 했다.Free Space공간 이 없 으 면 새로운 페이지 를 신청 해 야 한 다 는 것 을 의미한다.다른 것 은 특별한 점 이 없다.
4.6、Page Directory
이것 은 윗글 에서 토론 한 것 과 별 반 다 르 지 않 아 바로 뛰 어 넘 었 다.
4.7、File Trailer
이것 은 주로 페이지 가 디스크 에 들 어 가 는 과정 에서 극단 적 인 의외 의 상황(네트워크 문제,화재,자연 재해)으로 인해 실패 하고 데이터 가 일치 하지 않 는 상황 을 방지 하기 위해 서 이다.즉,더러 운 페이지 가 형성 되 었 다 는 것 이다.
안에 하나의 구성 부분 만 있다.

총화
여기 서 저 는 페이지 에 관 한 모든 것 이 다 르 지 않다 고 생각 합 니 다.밑바닥 의 페이지 원 리 를 알 게 되 었 습 니 다.저 는 개인 적 으로 MySQL 을 더욱 우호 적 이 고 이성적으로 사용 하 는 데 도움 이 되 고 자신 이 발휘 해 야 할 최고의 성능 을 발휘 할 수 있다 고 생각 합 니 다.
이상 은 MySQL 의 얕 은 입 심 출 페이지 원리 에 대한 상세 한 내용 입 니 다.MySQL 페이지 원리 에 관 한 자 료 는 저희 의 다른 관련 글 을 주목 해 주 십시오!