innodb 의 색인 페이지 구 조 를 말 하고 버퍼 를 삽입 하 며 해시 색인 에 적응 합 니 다.

Physical Structure of an InnoDB Index
모든 innodb 색인 은 btree 색인 이 고 색인 기록 은 잎 에 저 장 됩 니 다.기본 색인 페이지 크기 는 16K 입 니 다.새로운 기록 이 삽입 되 었 을 때 innodb 는 미래의 insert 와 update 작업 을 고려 하여 1/16 의 빈 페이지 크기 를 남 겨 두 려 고 시도 합 니 다.
색인 기록 이 색인 기록 의 크기 순서에 따라 완전히 삽입 된다 면 색인 도 전체 페이지 크기 의 15/16 을 채 울 것 입 니 다.삽입 순서 가 완전히 무 작위 라면 색인 페이지 는 기본적으로 1/2 에서 15/16 으로 채 워 집 니 다.충전 인자 가 1/2 보다 낮 으 면 innodb 는 b-tree 를 재 구축 하려 고 시도 합 니 다.
Mysql 5.6 이후 innodb 를 통 해page_size 매개 변 수 는 현재 인 스 턴 스 에서 각 색인 페이지 의 크기 를 설정 합 니 다.설정 하면 다시 변경 할 수 없습니다.추천 하 는 설정 은 보통 16K,8K 또는 4K 입 니 다.또한 Mysql 인 스 턴 스 가 기본 값 과 다른 innodb 를 설정 했다 면page_size A,그러면 A 값 과 다른 인 스 턴 스 의 파일 을 사용 할 수 없습니다(예 를 들 어 물리 적 백업 과 복구)
Insert Buffering
데이터 베 이 스 는 보통 메 인 키 순서대로 삽 입 됩 니 다.이 경우 색인 을 모 으 는 순서 와 이 메 인 키 의 순서 가 완전히 일치 하기 때문에 insert 작업 은 무 작위 IO 를 많이 줄 일 수 있 습 니 다.
다른 한편,2 급 색인 은 보통 유일한 것 이 아니 므 로 2 급 색인 에 데 이 터 를 삽입 할 때 상대 적 으로 무 작위 적 인 순서 이다.마찬가지 로 delete 와 update 작업 은 데이터 페이지 에 영향 을 줄 때 색인 변경 과 관련 되 며 2 급 색인 에 도 바짝 붙 어 있 지 않 습 니 다.이 로 인해 대량의 랜 덤 IO 가 발생 했다.
기록 을 삽입 하거나 유일한 2 급 색인 이 아 닌 기록 을 삭제 하면 innodb 는 먼저 이 2 급 색인 페이지 가 버퍼 에 있 는 지 확인 합 니 다.버퍼 에 있 으 면 innodb 는 메모리 에서 이 색인 페이지 를 직접 수정 합 니 다.이 색인 도 버퍼 에 없 으 면 innodb 는 이 수정 사항 을 삽입 버퍼,즉 insertbuffer 에 기록 합 니 다.Insert buffer 는 보통 작 기 때문에 버퍼 에 있 고 업데이트 가 빈번 합 니 다.이 수 정 된 프로 세 스 는 change buffering 입 니 다.(일반적으로 insert 작업 에 만 사용 되 기 때문에 insert buffering 이 라 고도 부 릅 니 다.이 데이터 구 조 는 insert buffer 입 니 다)
Disk I/O for Flushing the Insert Buffer
그럼 버퍼 삽입 은 어떻게 랜 덤 IO 를 줄 입 니까?한 동안 insert buffer 는 insert buffer 에 있 는 2 급 유일한 색인 이 아 닙 니 다.일반적으로 N 개 를 합 쳐 같은 btree 색인 페이지 에 수정 하여 많은 IO 작업 을 절약 합 니 다.테스트 를 통 해 insertbuffer 는 15 배의 삽입 속 도 를 높 일 수 있 습 니 다.
트 랜 잭 션 을 제출 한 후에 도 insert buffer 는 병합 해서 기록 할 수 있 습 니 다.따라서 DB 가 비정상적 으로 재 부팅 되 고 reovery 단계 에 서 는 2 급 색인 이 업데이트 되 거나 삽입 되 어야 할 때 insert buffer 는 몇 시간,심지어 몇 시간 이 걸 릴 수 있 습 니 다.이 단계 에서 디스크 IO 가 증가 하면 disk-bound 형식의 조회 가 현저 한 성능 을 떨 어 뜨 릴 수 있 습 니 다.
Adaptive Hash Indexes
해시 색인(AHI)에 적응 하여 innodb 는 버퍼 에 충분 한 메모리 와 일부 작업 부하 가 있어 메모리 데이터 베이스 처럼 보이 고 어떠한 업무 의 특징 과 안정성 도 희생 하지 않 습 니 다.이 특색 은 인자 innodbadaptive_hash_index 제어,동적 매개 변수,기본 값 은 on 으로 자체 적응 해시 색인 을 엽 니 다.AHI 를 닫 으 면 내 장 된 해시 표 가 즉시 비 워 집 니 다.정상 적 인 작업 은 계속 할 수 있 습 니 다.B-TREE 색인 에 직접 접근 할 수 있 습 니 다.AHI 를 다시 만 들 면 해시 표 가 다시 재건 된다.
검색 모드 를 관찰 하면 my sql 은 index key 의 접 두 사 를 이용 하여 해시 색인 을 만 듭 니 다.이 접 두 사 는 임의의 길이 일 수 있 으 며 b-tree 의 일부 값 일 수도 있 습 니 다.전체 b-tree 가 아 닙 니 다.해시 색인 은 검 사 를 통 해 자주 방문 하 는 index pages 에 해시 색인 을 만 듭 니 다.
표 가 거의 대부분 버퍼 에 있다 면 해시 색인 을 만 들 면 등가 조 회 를 가속 화하 고 btree 의 색인 값 을 정렬 지침 으로 변환 할 수 있 습 니 다.Innodb 는 이 메커니즘 을 가지 고 색인 검색 상황 을 감시 할 수 있 습 니 다.만약 에 일부 조회 가 해시 색인 을 만들어 서 조 회 를 최적화 할 수 있다 는 것 을 알 게 된다 면 자동 으로 만들어 질 것 입 니 다.그래서'적응 적'이 라 고 합 니 다.
일부 작업 부하 에서 해시 색인 을 통 해 가 져 온 성능 향상 가 치 는 이 추가 적 인 색인 검색 상황 을 감시 하고 이 해시 표 구 조 를 유지 하 는 데 가 져 온 비용 보다 훨씬 크다.그러나 어떤 때 는 부하 가 비교적 높 은 상황 에서 해시 색인 에 추 가 된 read/write 자물쇠 에 적응 하 는 것 도 경쟁 을 가 져 올 수 있다.예 를 들 어 높 은 병발 의 join 작업 이다.Like 동작 과%의 마스크 는 AHI 에 도 적용 되 지 않 습 니 다.작업 부하 가 AHI 에 적합 하지 않 으 면 불필요 한 성능 비용 을 가 져 오지 않도록 닫 는 것 을 권장 합 니 다.my sql 내부 에서 특정한 상황 에서 AHI 가 적당 한 지 예고 하기 어렵 기 때문에 실제 작업 부하 의 압력 측정(AHI 두 가지 상황 이 있 는 지 없 는 지)을 추천 합 니 다.5.6 및 이후 버 전에 서 는 점점 더 많은 작업 부하 가 해시 색인 에 적응 하 는 것 이 좋 습 니 다.비록 현재 로 서 는 기본적으로 열 려 있 지만.
해시 색인 생 성 은 기 존의 b-tree 를 기반 으로 합 니 다.innodb 는 b-tree 의 검색 상황 을 관찰 하여 임의의 길이 의 b-tree 색인 접 두 사 를 만 드 는 방식 으로 해시 색인 을 만 들 수 있 습 니 다.해시 색인 은 b-tree index 에서 가장 자주 방문 하 는 페이지 만 포함 할 수 있 습 니 다.
쇼 engine innodb status 결과 의 SEMAPHORES 부분 을 관찰 하여 자체 적응 해시 색인 을 사용 할 지 여 부 를 결정 할 수 있 습 니 다.btr0sea.c 파일 에 rw-latch 를 만 드 는 데 많은 스 레 드 를 보 았 다 면,자체 적응 해시 색인 을 닫 는 것 을 권장 합 니 다.본인 이 만 났 던 케이스 캡 처 는 다음 과 같 습 니 다.전형 적 인 고 병발 모델 에서 AHI 가 일 으 킨 경쟁 은 AHI 를 닫 아야 합 니 다.

이상 의 이 간단 한 innodb 의 색인 페이지 구 조 는 버퍼 를 삽입 합 니 다.하 쉬 색인 에 적응 하 는 것 은 바로 작은 편집 이 여러분 에 게 공유 하 는 모든 내용 입 니 다.여러분 께 참고 가 되 고 저 희 를 많이 사랑 해 주 셨 으 면 좋 겠 습 니 다.