이 기사에서는 스토리지 엔진 InnoDB 아키텍처에 대한 관련 내용을 주로 소개하는 mysql에 대한 관련 지식을 제공합니다. InnoDB는 트랜잭션 보안을 지원하는 스토리지 엔진인 MySQL의 기본 엔진에 대해 함께 살펴보겠습니다. 그것은 모두에게 도움이 됩니다.
추천 학습: mysql 비디오 튜토리얼
현재 MySQL8에서는 스토리지 최적화를 위한 많은 기능이 누락되었습니다. 따라서 현재 지원되는 9가지 데이터베이스 스토리지 엔진의 기능을 명확하게 이해하는 것은 학습할 가치가 있습니다. 이 문서에서는 이러한 8가지 데이터베이스 스토리지 엔진의 기능, 기능 및 사용 시나리오를 명확하게 설명합니다.
이 일련의 기사는 SQL을 사용하여 일상적인 비즈니스, 정기적인 쿼리 데이터베이스 분석 및 복잡한 작업을 처리하는 방법의 모든 측면을 기본적으로 다루는 "SQL 데이터베이스 작업 빠르게 배우기" 칼럼에 포함됩니다. 데이터베이스와 테이블을 구축하는 기본 단계부터 다양하고 복잡한 데이터베이스 작업 처리는 물론, 일반적인 SQL 기능에 대한 전문적인 설명까지, 생성에 많은 시간과 노력을 들였습니다. 데이터 개발, 가장 실용적이고 일반적으로 사용되는 지식을 처음으로 배우려면 칼럼 구독을 권장합니다. 이 블로그는 꽤 길기 때문에 주의 깊게 읽고 연습할 가치가 있습니다. 가장 좋은 부분을 선택하고 연습 방법을 자세히 설명하겠습니다. 블로거는 오랫동안 블로그 게시물을 관리할 것입니다. 오류나 의심스러운 점이 있으면 댓글란에 지적해 주시기 바랍니다.
MySQL 데이터베이스에 들어가 스토리지 엔진을 보면 MySQL 데이터베이스에서 지원하는 모든 스토리지 엔진을 볼 수 있습니다.
SHOW ENGINES
현재 Federated가 지원하지 않는 엔진이 하나 있습니다. 나머지 8개만 알면 됩니다. 데이터베이스 저장소는 괜찮습니다.
MySQL의 일반적인 데이터베이스 엔진에는 MyISAM, InnoDB 및 Memory가 포함됩니다. 그럼 먼저 이 세 가지 엔진을 이해해 봅시다.
InnoDB는 트랜잭션 보안을 지원하는 스토리지 엔진인 MySQL의 기본 엔진입니다. MySQL의 데이터는 물리적 디스크에 저장되고 실제 데이터 처리는 메모리에서 수행됩니다. 디스크의 읽기 및 쓰기 속도가 매우 느리기 때문에 각 작업마다 디스크를 자주 읽고 쓰면 성능이 매우 저하됩니다.
위 문제를 해결하기 위해 InnoDB는 디스크와 메모리 간의 상호 작용의 기본 단위로 페이지를 사용하여 데이터를 여러 페이지로 나눕니다. 이 경우 한 번에 최소 1페이지의 데이터가 메모리로 읽혀지거나 1페이지의 데이터가 디스크에 기록됩니다. 메모리와 디스크 간의 상호 작용 수를 줄여 성능을 향상시킵니다.
이것은 본질적으로 전형적인 캐시 설계 아이디어입니다. 일반적으로 캐시 설계는 기본적으로 시간 차원 또는 공간 차원에서 고려됩니다.
시간 차원: 데이터 조각이 사용되면 다음이 될 가능성이 높습니다. 일정 기간 내에 다시 사용됩니다. 핫스팟 데이터 캐싱은 이 아이디어의 구현에 속한다고 간주할 수 있습니다.
공간적 차원: 데이터 조각이 사용되고 있다면 그 근처에 저장된 데이터도 곧 사용될 확률이 높습니다. InnoDB의 데이터 페이지와 운영 체제의 페이지 캐시는 이 아이디어의 구현입니다.
다음은 공식 InnoDB 엔진 구조 다이어그램으로, 주로 메모리 구조와 디스크 구조의 두 부분으로 나뉩니다.
메모리 구조에는 주로 버퍼 풀, 변경 버퍼, 적응형 해시 인덱스 및 로그 버퍼의 네 가지 구성 요소가 포함됩니다.
버퍼 풀은 데이터, 인덱스, 삽입 버퍼, 적응형 해시 인덱스, 잠금 정보 및 데이터 사전으로 구성됩니다. BP라고 하는 버퍼 풀. BP는 페이지를 기반으로 하며 기본 크기는 16K입니다. BP의 하위 계층은 페이지를 관리하기 위해 연결된 목록 데이터 구조를 사용합니다. InnoDB가 테이블 레코드와 인덱스에 액세스하면 페이지 페이지에 캐시됩니다. 나중에 사용하면 디스크 IO 작업이 줄어들고 효율성이 향상됩니다.
버퍼 풀은 단순히 메모리 속도를 사용하여 느린 디스크 속도가 데이터베이스 성능에 미치는 영향을 보상하는 메모리 영역입니다. 데이터베이스에서 페이지를 읽을 때 디스크에서 읽은 페이지는 먼저 버퍼 풀에 저장됩니다. 이 프로세스를 버퍼 풀의 페이지를 "수정"이라고 합니다. 다음에 동일한 페이지를 읽을 때 먼저 페이지가 버퍼 풀에 있는지 확인하십시오. 버퍼 풀에 있는 경우 페이지가 버퍼 풀에 도달했다고 합니다. 페이지를 직접 읽어보세요. 그렇지 않으면 디스크의 페이지를 읽습니다. 데이터베이스의 페이지 수정 작업의 경우 버퍼 풀의 페이지가 먼저 수정된 후 특정 빈도로 디스크에 새로 고쳐집니다. 여기서 주목해야 할 점은 버퍼 풀에서 디스크로 페이지를 다시 플러시하는 작업은 페이지가 업데이트될 때마다 트리거되는 것이 아니라 체크포인트(Checkpoint)라는 메커니즘을 통해 디스크로 다시 플러시된다는 점입니다. 이는 데이터베이스의 전반적인 성능을 향상시키기 위한 것입니다.
전통적인 LUR 알고리즘
버퍼 풀은 LRU(Latest Recent Used, Least Recent Used) 알고리즘을 통해 관리됩니다. 즉, 가장 자주 사용되는 페이지가 LRU 목록의 맨 앞에 있고 가장 적게 사용되는 페이지가 옵니다. 페이지는 LRU 목록의 맨 앞에 있습니다. 목록의 끝에서 버퍼 풀이 새로 읽은 페이지를 저장할 수 없으면 LRU 목록의 끝에 있는 페이지가 먼저 해제됩니다.
(1) 페이지가 이미 들어 있습니다. 버퍼 풀이므로 LRU 작업의 헤드로 "이동"하지만 페이지는 제거되지 않습니다.
(2) LRU 헤드를 "넣는" 작업 외에 페이지가 버퍼 풀에 없습니다. , LRU 테일 페이지를 "제거"하는 작업도 수행됩니다.
하지만 InnoDB의 LUR 알고리즘은 전통적인 LUR 알고리즘이 아닙니다.
여기에는 두 가지 문제가 있습니다.
(1) 미리 읽기 실패;
(2) 버퍼 풀 오염
먼저 미리 읽기가 무엇인지 이해해 봅시다. 읽기 및 쓰기, 요청 시 읽는 것이 아니라 페이지 단위로 읽는 것입니다. 한 번에 최소 한 페이지(보통 4K)의 데이터를 읽습니다. 나중에 읽을 데이터가 해당 페이지에 있으면 후속 디스크입니다. IO를 생략할 수 있어 효율성을 높일 수 있습니다. 데이터 접근은 일반적으로 '집중 읽기 및 쓰기' 원칙을 따릅니다. 일부 데이터를 사용할 경우 근처의 데이터가 사용될 확률이 높습니다. 이는 조기 로딩이 효과적임을 보여주는 소위 '지역성 원칙'입니다. 실제로 디스크 IO를 줄일 수 있습니다.
미리 읽기 실패
미리 읽기(Read-Ahead)로 인해 페이지를 미리 버퍼 풀에 넣지만 결국 MySQL은 페이지의 데이터를 읽지 못하는데, 이는 미리 읽기 실패라고 합니다.
미리 읽기 실패를 최적화하기 위한 아이디어는 다음과 같습니다. (1) 미리 읽기에 실패한 페이지를 가능한 한 짧은 시간 동안 버퍼 풀 LRU에 유지합니다. (2) 페이지를 그대로 유지합니다. 실제로 읽은 핫 데이터가 버퍼 풀에 최대한 오래 머물도록 하기 위해 버퍼 풀 LRU의 헤드로 이동합니다.
구체적인 방법은 다음과 같습니다.
(1) LRU를 두 부분으로 나눕니다.
New Generation(new sublist)
Old Generation(old sublist)
(2) New Generation과 Old Generation은 마지막에 연결됩니다. , 즉: new Generation 세대의 꼬리는 Old 세대의 선두에 연결됩니다.
(3) 새 페이지(예: 미리 읽은 페이지)가 버퍼 풀에 추가되면 추가만 됩니다. 구세대의 선두에:
데이터가 실제로 읽고 있는 경우(미리 읽기 성공)는 새로운 세대의 선두에 추가됩니다.
데이터를 읽지 않으면 버퍼 풀에서 제거됩니다. 새로운 세대의 "핫 데이터 페이지"보다 앞서
신학생과 기존 학생 LRU의 개선된 버전은 여전히 버퍼 풀 오염 문제를 해결할 수 없습니다.
2.로그 버퍼
로그 버퍼는 리두 로그를 캐시하는 데 사용됩니다.
InnoDB에는 매우 중요한 두 가지 로그가 있습니다: undo 로그와 redo 로그
(1) undo 로그를 통해 이전 버전의 데이터 확인, MVCC 구현 또는 트랜잭션 롤백 및 기타 기능을 수행할 수 있습니다.
(2) 리두 로그를 사용하여 트랜잭션 내구성을 보장합니다.
리두 로그 버퍼는 디스크의 로그 파일에 기록될 데이터를 보관하는 데 사용되는 메모리 저장 영역입니다. 로그 버퍼 크기는 innodb_log_buffer_size 변수로 정의되며 기본 크기는 16MB입니다. 로그 버퍼의 내용은 주기적으로 디스크로 플러시됩니다. 더 큰 로그 버퍼를 사용하면 트랜잭션이 커밋되기 전에 리두 로그 데이터가 디스크에 기록되지 않고도 대규모 트랜잭션을 실행할 수 있습니다. 따라서 많은 행을 업데이트, 삽입 또는 삭제하는 트랜잭션이 있는 경우 로그 버퍼 크기를 늘리면 디스크 I/O를 줄일 수 있습니다. innodb_flush_log_at_trx_commit: 로그 버퍼의 내용이 디스크에 기록되고 플러시되는 방식을 제어합니다. innodb_flush_log_at_timeout: 로그 새로 고침 빈도를 제어합니다.
많은 BLOB 항목이 포함된 트랜잭션과 같이 디스크 I/O로 인해 성능 문제가 발생하는 경우 트랜잭션을 관찰해야 합니다. InnoDB 로그 버퍼는 가득 찰 때마다 디스크로 플러시되므로 버퍼 크기를 늘리면 I/O가 줄어들 수 있습니다.
기본 로그 파일 수는 ib_logfile0과 ib_logfile1의 두 개입니다.
로그의 크기는 고정되어 있으며 기본 크기는 MySQL 버전에 따라 다릅니다.
3.적응형 해시 인덱스
적응형 해시 인덱스 적응형 해시 인덱스는 핫 페이지가 위치한 레코드를 저장하는 키-값 쌍 저장 구조입니다. InnoDB 스토리지 엔진은 액세스 빈도와 패턴을 기반으로 특정 페이지에 대한 해시 인덱스를 자동으로 생성합니다.
위 사진은 B+트리 인덱스와 적응형 해시 인덱스의 차이입니다. 기본적으로 활성화되어 있는 innodb_adaptive_hash_index 매개변수를 통해 이 기능을 비활성화하거나 활성화합니다. 4.Change BufferChange Buffer: MySQL의 데이터는 메모리와 디스크의 두 부분으로 나누어집니다. 핫 데이터 페이지와 인덱스 페이지는 디스크 읽기를 줄이기 위해 버퍼 풀에 캐시됩니다. . 수단.데이터 페이지를 업데이트해야 할 때 데이터 페이지가 메모리에 있으면 직접 업데이트하세요. 데이터 페이지가 메모리에 없는 경우. 데이터 일관성에 영향을 주지 않고 InooDB는 이러한 업데이트 작업을 변경 버퍼에 캐시하므로 디스크에서 이 데이터 페이지를 읽을 필요가 없습니다. 다음 쿼리가 이 데이터 페이지에 액세스해야 하는 경우 데이터 페이지를 메모리로 읽은 다음 변경 버퍼에서 이 페이지와 관련된 작업을 수행합니다. 이러한 방식으로 데이터 로직의 정확성이 보장될 수 있습니다.
이름은 체인지 버퍼라고 하지만 실제로는 영속성이 있는 데이터입니다. 즉, 변경 버퍼는 메모리에 복사본을 갖고 있으며 디스크(ibdata)에도 기록됩니다.
변경 버퍼의 작업을 원본 데이터 페이지에 병합하고 최신 결과를 얻는 과정을 병합이라고 합니다. 다음 상황에서는 병합이 시작됩니다.
이 데이터 페이지에 액세스합니다.
백그라운드 마스터 스레드가 정기적으로 병합됩니다.
데이터베이스 버퍼 풀이 충분하지 않은 경우; 일반적으로
redo 로그가 가득 차면
변경 버퍼는 고유하지 않은 일반 인덱스 페이지가 버퍼 풀에 없고 페이지에서 쓰기 작업이 수행될 때 레코드 변경 버퍼가 먼저 버퍼링된 후 향후 데이터를 읽을 때 레코드가 변경됩니다. 변경 버퍼에 있는 기술을 원본 데이터 페이지에 병합합니다. MySQL5.5 이전에는 삽입 버퍼(insert buffer)라고 불리며 삽입에만 최적화되었지만 이제는 삭제 및 업데이트에도 유효하며 쓰기 버퍼(change buffer)라고 합니다.
위 내용은 InnoDB 아키텍처에 대한 MySQL 스토리지 엔진 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
