MySQL 버퍼 풀의 변경 버퍼 소개

4 변경 버퍼

4.1 기본 개념

변경 버퍼는 해당 페이지가 버퍼 풀에 없을 때 보조 인덱스 페이지의 변경 사항을 캐시하는 특수 데이터 구조입니다. INSERT, UPDATE 또는 DELETE 작업(DML)으로 인해 발생할 수 있는 버퍼 변경 사항은 나중에 페이지가 다른 읽기 작업에 의해 버퍼 풀에 로드될 때 병합됩니다.

관련 무료 학습 추천: mysql 동영상 튜토리얼

위 그림에서 볼 수 있듯이 변경 버퍼는 버퍼 풀에 있는 메모리를 사용하므로 무한히 커질 수 없습니다. 변경 버퍼 크기는 innodb_change_buffer_max_size 매개변수를 통해 동적으로 설정할 수 있습니다.
예를 들어 50으로 설정하면 변경 버퍼의 크기는 버퍼 풀의 최대 50%까지만 차지할 수 있습니다.

데이터 페이지를 업데이트해야 하는 경우:

• 페이지는 메모리에 있고
• 페이지는 데이터 일관성에 영향을 주지 않고 직접 업데이트됩니다. InooDB는 이러한 업데이트 작업을 디스크에서 읽지 않고 변경 버퍼에 캐시합니다.

페이지는 다음 쿼리가 데이터 페이지에 액세스할 때만 데이터 페이지를 메모리로 읽어온 다음 변경 버퍼에서 이 페이지와 관련된 작업을 수행합니다. 이러한 방식으로 데이터 로직의 정확성이 보장될 수 있습니다.

변경 버퍼는 실제로 영구 데이터입니다. 즉, 메모리에 복사될 뿐만 아니라 디스크에도 기록됩니다.

4.2 merge

최신 결과를 얻기 위해 변경 버퍼의 작업을 원본 데이터 페이지에 적용하는 프로세스입니다.

4.2.1 트리거 타이밍

1. 데이터 페이지에 액세스
2. 시스템 백그라운드 스레드가 정기적으로 병합됩니다
3. 데이터베이스가 정상적으로 종료되는 과정(shutdown)

업데이트 작업이 먼저 변경 버퍼에 기록될 수 있는 경우 , 디스크 읽기를 줄일 수 있으며 명령문 실행 속도가 크게 향상됩니다. 그리고 데이터를 메모리로 읽어오려면 버퍼 풀을 점유해야 하므로 메모리 사용량을 줄이고 메모리 활용도를 높일 수도 있습니다.

4.3 변경 버퍼를 사용해야 하는 경우

• 고유 인덱스의 경우 업데이트 작업은 먼저 작업이 고유성 제약 조건을 위반하는지 여부를 확인해야 합니다.
  예를 들어 (4,400)개의 레코드를 삽입하려면 먼저 k가 이미 테이블 =4 레코드에 저장되어 있으므로 판단하려면 데이터 페이지를 메모리로 읽어야 합니다. 모든 내용을 메모리에 읽어 들인 경우 메모리를 직접 업데이트하는 것이 매우 빠르며 변경 버퍼를 사용할 필요가 없습니다.
  따라서 고유 인덱스 업데이트에는 변경 버퍼를 사용할 수 없으며 일반 인덱스만 사용할 수 있습니다 .

4.4 적용 가능한 시나리오

변경 버퍼를 사용하면 일반 인덱싱의 모든 시나리오를 가속화할 수 있나요?

병합은 데이터가 실제로 업데이트되는 시간입니다. 변경 버퍼는 주로 기록된 변경 작업을 캐시합니다. 따라서 데이터 페이지가 병합되기 전에 변경 버퍼 레코드에 변경 사항이 많을수록(즉, 데이터 페이지를 업데이트해야 하는 횟수가 많을수록) 이점이 더 커집니다.

• 더 많이 쓰고 덜 읽으세요. 쓰기 직후에 페이지에 액세스할 확률은 적습니다. 변경 버퍼를 사용하는 것이 가장 좋습니다. 일반적으로 사용되는 것은 청구 및 로그 시스템입니다.
• 쓰기 후 즉시 쿼리하면 새 레코드가 먼저 변경 버퍼에 기록되지만 데이터 페이지에 즉시 액세스하여 병합이 빠르게 트리거됩니다. 이 경우 랜덤 액세스 IO 수가 발생하지 않습니다. 감소하지만 변경 버퍼의 유지 관리 비용이 증가하고 변경 버퍼가 증가합니다.

더 많은 관련 무료 학습 권장 사항: mysql 튜토리얼(동영상)

위 내용은 MySQL 버퍼 풀의 변경 버퍼 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!