MySQL에서 페이지 버퍼 풀을 읽는 방법에 대한 지식 포인트는 무엇입니까?

버퍼 풀

우리 모두는 페이지를 읽을 때 먼저 디스크에서 메모리로 페이지를 읽은 다음 CPU가 데이터를 처리할 때까지 기다려야 한다는 것을 알고 있습니다. 디스크에서 메모리로 데이터를 읽는 과정은 매우 느리기 때문에 우리가 읽는 페이지를 캐시해야 하므로 MySQL에는 페이지를 캐시하기 위한 버퍼 풀이 있습니다.

먼저 MySQL은 시작할 때 운영체제에서 연속적인 메모리 공간을 적용하게 되는데 이 공간이 버퍼 풀로 사용됩니다. 캐시된 페이지를 버퍼 풀에 넣고 관리합니다.

mysql> show variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set, 1 warning (0.00 sec)

기본값은 134217728바이트, 즉 128MB임을 알 수 있습니다. 우리가 신청하는 캐시 크기가 16KB의 배수인 경우 각 페이지 크기가 16KB이므로 조각화 문제가 없습니다.

버퍼 풀 구성

각 페이지에는 버퍼 풀에 저장되는 해당 제어 블록 정보가 포함되어 있습니다. 각 제어 블록은 각 페이지를 관리합니다(우리는 각 페이지를 참조하기 위해 주소를 사용합니다). 제어 블록은 페이지에 대한 일부 정보를 저장하는 데 사용됩니다. 제어 블록의 점유 크기는 innodb_buffer_pool_size에 포함되지 않습니다. MySQL은 시작 시 추가 공간을 적용합니다.

공간을 완전히 활용할 수 없기 때문에 컨트롤 블록과 캐시 페이지 사이에 불규칙한 조각화가 발생합니다. MySQL이 운영체제에 적용하는 메모리 공간은 일정 크기의 제어 블록 공간이 필요하고, 구체적인 크기를 알 수 없기 때문에 사용할 수 없는 공간이 생길 수밖에 없다.

free linked list

free linked list는 이름에서 알 수 있듯이 무료 캐시 페이지를 관리하는 연결 목록입니다. 캐시 페이지를 사용하지 않으면 해당 컨트롤 블록이 무료 연결 목록에 연결됩니다.

베이스 노드를 통해 컨트롤 블록을 연결하여 자유 연결 리스트를 형성하고, 자유 페이지 수 등 기본 정보를 저장합니다.

디스크에서 버퍼 풀로 페이지를 읽어올 때 빈 제어 블록을 가져와 해당 캐시 페이지의 기본 정보를 채웁니다.

캐시된 페이지의 해시 처리

MySQL은 어떻게 버퍼 풀의 페이지에 빠르게 액세스하고 해당 페이지가 버퍼 풀에 캐시되었는지 확인합니까?

이것은 Java의 해시맵인 해시 테이블을 사용하여 테이블스페이스 + 페이지 번호를 처리하여 해시 키 값을 형성하며, 그 값은 버퍼 풀에 있는 캐시 페이지의 주소입니다.

플러시 링크드 리스트 관리

이 장을 접하고는 정말 충격을 받았고, 나중에 MVCC를 보고 다시 눈을 떴습니다. 나중에 요약할 예정이므로 더 간결하고 요점이 명확해졌습니다.

SQL문을 사용하여 특정 레코드를 수정하는 경우 특정 페이지 또는 여러 페이지를 수정하게 됩니다. 페이지를 수정하는 경우 디스크 IO가 매우 어렵기 때문에 디스크에 직접 해당 수정을 수행하지 않습니다. 너무 느립니다. 먼저 수정된 페이지(간단히 말하면 더티 페이지)를 링크하겠습니다. 이는 더티 페이지에 해당하는 제어 블록을 함께 연결하는 기본 노드입니다.

이 플러시 연결 목록은 아직 페이지를 디스크에 업데이트하지 않은 연결 목록을 나타냅니다.

LRU linked list

버퍼 풀의 크기가 제한되어 있기 때문에 캐시 페이지의 크기도 제한되어 있으므로 사용하지 않는 페이지를 제거해야 합니다. MySQL은 제거를 위해 LRU 방법을 사용합니다.

LRU는 가장 오랫동안 사용되지 않은 제거 전략입니다. 연결 목록을 사용하여 캐시된 페이지를 연결합니다. 가장 최근에 액세스한 페이지가 맨 앞에 표시되고, LRU가 가득 차면 가장 적게 액세스한 페이지가 표시됩니다. 새로운 페이지가 들어오고 연결된 목록의 끝에 있는 페이지를 제거할 수 있는 기회가 생깁니다.

MySQL이 사전 읽기 또는 전체 테이블 스캔을 수행할 때 많은 수의 저주파 페이지가 LRU 연결 목록으로 읽혀지며, 이로 인해 고주파 페이지가 직접 제거되고 드물게 일부 페이지로 대체됩니다. 사용된 페이지.

MySQL 최적화 프로그램은 쿼리 성능을 향상시키기 위해 쿼리에서 액세스할 것으로 예상되는 페이지를 메모리 버퍼 풀에 미리 로드합니다. 두 가지 유형으로 나눌 수 있습니다:

• Linear read-ahead

영역에서 페이지를 읽을 때 시스템 변수 innodb_read_ahead_threshold의 값을 초과하면 기본값은 56, 즉 페이지를 읽을 때입니다. 영역에서 56페이지를 초과하면 MySQL 다음 영역의 모든 페이지가 메모리로 비동기적으로 읽혀집니다.

• Random read-ahead

버퍼 풀이 특정 영역의 13페이지를 캐시했다면 순차적인지 여부에 관계없이 13페이지가 캐시되어 있으면 MySQL이 트리거되어 모든 페이지를 읽습니다. 이 영역의 페이지를 MySQL에 비동기적으로 보냅니다. 시스템 변수 innodb_random_read_ahead를 설정하여 무작위 미리 읽기를 끌 수 있습니다. 기본값은 꺼짐입니다.

그래서 연결된 목록을 두 부분으로 나누는 향상된 파티션 기반 LRU 연결 목록이 있습니다.

하나는 자주 사용되는 젊은 영역이고, 다른 하나는 자주 사용되지 않는 오래된 영역입니다.

正常来说old区占比是37％，所以young区就占63％，我们可以通过innodb_old_blocks_pct来修改，默认就是37。

我们来讲讲这个基于分区的LRU链表。

1. 首先buffer pool初始化，会将读取的页面直接放进old区。

• 但是如果我们对于同一个页面的多条记录进行访问的话，我们就会多次访问同一页多次。但是如果我们是全表扫描的话，是可能会将所有页面缓存进缓存池中的，所以MySQL对于其进行优化。

• 所以MySQL对于当页面第一次读入old区并在一定时间间隔（innodb_old_blocks_pct）内的多次访问来说是不会将其放入young区进行缓存的。innodb_old_blocks_pct的值默认为1000，就是刚来的来一秒内的多次访问是不会将其转移到young区的。

1. 如果多次访问就会将old区的页升级到young区。当young区的页面被访问，只有young链表后1/4的页面被访问时才会将其转置到young区链表头，不然就不会改动，减少一些调整链表的性能损失。

刷新脏页

MySQL会启动后台线程进行脏页，也就是修改的页面进行刷新到磁盘。

以下有两种方式刷新脏页：

• 从LRU的尾部扫描一些页面，刷新其中的脏页到磁盘中。

• 在LRU链表的old区域尾部，即不经常使用的页面中，后台线程会查找是否存在脏页，如果有，则将其更新至磁盘。控制扫描区域尾部数量的方法是更改系统变量innodb_lru_scan_depth。

• 从flush链表中更新到磁盘。

• 我们上面说了flush连接这脏页的控制块，我们就可以将连接这flush链表的脏页进行更新。

疑问：为什么要两种方式更新呢？我刚开始不懂这是我回过头来看的时候就懂了

首先我们脏页是缓存在buffer pool中的，但是我们buffer pool空间是有限的，又因为我们使用的是LRU的方式，又因为从flush链表将脏页同步到磁盘效率实在不高，所以不会很经常去更新脏页。如果我们不更新直接将其从LRU的链表抛弃也就是从缓存池中直接扔了，但是它是脏页就无法同步到磁盘了，同时flush链表链接的也会出现问题。

所以在LRU淘汰很久未使用的页有个前提就是它不是一个脏页。为了淘汰这些页面，我们需要检查LRU链表的末尾是否存在脏页并进行更新。

flush链表更新那就是它的本职工作了，它存这个也是干这个的，应该没有什么问题。

当系统十分繁忙，buffer pool使用量不足的时候，因为磁盘IO太慢了，所以会出现一种情况，就是大量的用户线程也在进行这个同步脏页的活。如果未进行脏页同步并淘汰缓冲池的页面，则无法读取该页面。

多个buffer pool实例

我们可以设置多个buffer pool来实现多实例提高性能。

mysql> show variables like 'innodb_buffer_pool_instances';
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| innodb_buffer_pool_instances | 1     |
+------------------------------+-------+
1 row in set, 1 warning (0.00 sec)

我们可以设置innodb_buffer_pool_instances系统变量来控制实例变量。

但是当buffer pool的大小小于1G的时候，设置2个实例也是没有用的（会被恢复成1个），多实例的情况是建立在大内存的情况下的。

动态调整buffer pool大小

在MySQL5.7.5后，MySQL中的buffer pool的大小是以chunk来分配了，如下图。

一个buffer pool是由多个chunk组成的，所以MySQL向操作系统申请连续的内存空间，就是以chunk的方式来申请的，这样我们可以在MySQL运行时调整buffer pool的大小。在运行时更改chunk大小不可行，并且会造成性能浪费。？

innodb_buffer_pool_size / innodb_buffer_pool_instances = 每个实例buffer pool的大小。

每个实例的大小 / innodb_buffer_pool_chunk_size = 每个实例由多少个chunk构成。

不是弄很明白，怎么动态调整大小，我调整了但是mysqld占用内存大小还是只能重启才能生效，我不会。

查看buffer pool具体的信息

show engine innodb status;

위 내용은 MySQL에서 페이지 버퍼 풀을 읽는 방법에 대한 지식 포인트는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!