Quels sont les points de connaissances sur la lecture du pool de tampons de pages dans MySQL ?-tutoriel mysql-php.cn

Piscine tampon

Nous savons tous que lors de la lecture d'une page, nous devons d'abord lire la page du disque vers la mémoire, puis attendre que le processeur traite les données. Le processus de lecture des données du disque vers la mémoire est très lent, les pages que nous lisons doivent donc être mises en cache, donc MySQL dispose de ce pool de tampons pour mettre les pages en cache.

Tout d'abord, MySQL demandera un espace mémoire continu au système d'exploitation lors de son démarrage. Cet espace est utilisé comme pool de mémoire tampon. Placez les pages mises en cache dans le pool de mémoire tampon et gérez-les.

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

Copier après la connexion

Nous pouvons voir que la valeur par défaut est de 134217728 octets, soit 128 Mo. Si la taille du cache que nous demandons est un multiple de 16 Ko, il n'y aura pas de problème de fragmentation car chaque taille de page est de 16 Ko.

Composition du pool de tampons

Chaque page contient les informations de bloc de contrôle correspondantes, qui sont stockées dans le pool de tampons. Chaque bloc de contrôle gère chaque page (nous utilisons l'adresse pour référencer chaque page). Le bloc de contrôle est utilisé pour stocker certaines informations sur la page. La taille occupée du bloc de contrôle n'est pas incluse dans innodb_buffer_pool_size. MySQL demande de l'espace supplémentaire au démarrage.

Quels sont les points de connaissances sur la lecture du pool de tampons de pages dans MySQL ?

En raison de l'incapacité d'utiliser pleinement l'espace, il y aura une fragmentation irrégulière entre le bloc de contrôle et la page de cache. Étant donné que l'espace mémoire que MySQL applique au système d'exploitation nécessite une certaine taille d'espace de bloc de contrôle et que la taille spécifique ne peut pas être déterminée, il est inévitable qu'il y ait de l'espace inutilisable.

liste chaînée gratuite

liste chaînée gratuite, comme son nom l'indique, est une liste chaînée qui gère les pages de cache gratuites. Si la page de cache n'est pas utilisée, son bloc de contrôle sera connecté à la liste chaînée gratuite.

Quels sont les points de connaissances sur la lecture du pool de tampons de pages dans MySQL ?

Connectez le bloc de contrôle via un nœud de base pour former une liste chaînée gratuite et stockez des informations de base telles que le nombre de pages gratuites.

Lorsque nous lisons une page du disque dans le pool de tampons, nous prendrons un bloc de contrôle gratuit et remplirons les informations de base de la page de cache correspondante.

Traitement de hachage des pages mises en cache

Comment MySQL accède-t-il rapidement à une page dans le pool de tampons et vérifie-t-il si la page correspondante a été mise en cache dans le pool de tampons ?

Cela utilise une table de hachage, qui est une hashmap en Java. Elle traite l'espace table + le numéro de page pour former une valeur de clé de hachage, puis la valeur est l'adresse de la page de cache dans le pool de tampons.

Gestion des listes chaînées flush

J'ai été choqué quand j'ai appris ce chapitre. Tout d'abord, il était effectivement différent de ma compréhension, et le MVCC ultérieur m'a vraiment ouvert les yeux. Je vais le résumer plus tard, donc c'est plus concis et précis.

Lorsque nous utilisons des instructions SQL pour modifier un certain enregistrement, nous modifierons une certaine page ou plusieurs pages. Lorsque nous modifierons la page, nous n'apporterons pas directement les modifications correspondantes au disque, car les E/S du disque sont très difficiles. trop lent. Nous allons d'abord lier les pages modifiées (pages sales en abrégé), ce qui est similaire à la liste chaînée gratuite. C'est un nœud de base qui relie les blocs de contrôle correspondant aux pages sales entre eux.

Cette liste chaînée affleurante représente la liste chaînée dont nous n'avons pas encore mis à jour la page sur le disque.

Quels sont les points de connaissances sur la lecture du pool de tampons de pages dans MySQL ?

Liste chaînée LRU

Étant donné que la taille du pool de tampons est limitée, la taille de nos pages de cache est limitée, nous devons donc éliminer les pages inutilisées. MySQL utilise la méthode LRU pour l'élimination.

LRU est la stratégie d'élimination inutilisée la plus longue. Nous utilisons une liste chaînée pour lier les pages mises en cache. Les pages les plus récemment consultées apparaissent au début, et les pages les moins consultées sont à la fin de la liste chaînée. de nouvelles pages arriveront et auront la possibilité d'éliminer les pages à la fin de la liste chaînée.

Nous utilisons LRU directement. Lorsque MySQL effectue une pré-lecture ou une analyse de table complète, un grand nombre de pages basse fréquence sont lues dans la liste chaînée LRU, ce qui entraînera l'élimination directe des pages haute fréquence et leur remplacement par d'autres rarement. pages utilisées.

L'optimiseur MySQL préchargera les pages auxquelles les requêtes devraient accéder dans le pool de mémoire tampon pour améliorer les performances des requêtes. Elle peut être divisée en deux types :
Lecture anticipée linéaire
Lorsque la lecture des pages d'une zone dépasse la valeur de la variable système innodb_read_ahead_threshold, la valeur par défaut est 56, c'est-à-dire lorsque l'on lit les pages dans une zone dépasse 56 pages, MySQL Toutes les pages de la zone suivante seront lues de manière asynchrone en mémoire.
Lecture anticipée aléatoire
Si le pool de mémoire tampon a mis en cache 13 pages dans une certaine zone, qu'elles soient séquentielles ou non, tant qu'il y a 13 pages en cache, MySQL sera déclenché pour tout lire pages de cette zone de manière asynchrone dans MySQL. La variable système innodb_random_read_ahead peut être définie pour désactiver la lecture anticipée aléatoire. La valeur par défaut est DÉSACTIVÉ.

Il existe donc une liste chaînée LRU améliorée basée sur des partitions, qui divise la liste chaînée en deux parties.

L'une est la zone jeune qui est très fréquemment utilisée, et l'autre est la zone ancienne qui n'est pas utilisée très fréquemment.

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

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

首先buffer pool初始化，会将读取的页面直接放进old区。
但是如果我们对于同一个页面的多条记录进行访问的话，我们就会多次访问同一页多次。但是如果我们是全表扫描的话，是可能会将所有页面缓存进缓存池中的，所以MySQL对于其进行优化。
所以MySQL对于当页面第一次读入old区并在一定时间间隔（innodb_old_blocks_pct）内的多次访问来说是不会将其放入young区进行缓存的。innodb_old_blocks_pct的值默认为1000，就是刚来的来一秒内的多次访问是不会将其转移到young区的。
如果多次访问就会将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 &#39;innodb_buffer_pool_instances&#39;;
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| innodb_buffer_pool_instances | 1     |
+------------------------------+-------+
1 row in set, 1 warning (0.00 sec)

Copier après la connexion

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

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