Explication détaillée du moteur de stockage MySQL sur l'architecture InnoDB

Cet article vous apporte des connaissances pertinentes sur mysql, qui présente principalement le contenu pertinent sur l'architecture du moteur de stockage InnoDB. InnoDB est le moteur par défaut de MySQL, un moteur de stockage qui prend en charge la sécurité des transactions, examinons-le ensemble, j'espère. ça aide tout le monde.

Apprentissage recommandé : Tutoriel vidéo mysql

Actuellement, le MySQL8. En conséquence, de nombreuses fonctions d'optimisation du stockage sont manquées. Par conséquent, il vaut la peine d’apprendre à bien comprendre les fonctions des neuf moteurs de stockage de bases de données actuellement pris en charge. Cet article explique clairement les fonctions, fonctions et scénarios d'utilisation de ces huit moteurs de stockage de bases de données.

Cette série d'articles sera incluse dans ma chronique - Apprendre rapidement diverses opérations de base de données SQL, qui couvre essentiellement tous les aspects de l'utilisation de SQL pour gérer les affaires quotidiennes, l'analyse régulière de la base de données de requêtes et les opérations complexes. Depuis les étapes de base de la création de bases de données et de tables jusqu'à la gestion de diverses opérations de bases de données complexes, en passant par les explications professionnelles des fonctions SQL courantes, beaucoup de temps et d'efforts ont été consacrés à la création. Si vous avez des amis qui ont besoin de s'engager dans l'analyse ou l'analyse de données. développement de données, je recommande de vous abonner à la rubrique Apprenez les connaissances les plus pratiques et les plus couramment utilisées dans un premier temps. Ce blog est assez long et mérite une lecture et une pratique attentives. Je sélectionnerai les meilleures parties et expliquerai la pratique en détail. Le blogueur maintiendra l'article de blog pendant une longue période. Si vous avez des erreurs ou des doutes, vous pouvez les signaler dans la zone de commentaires. Merci pour votre soutien.

1. Moteurs de stockage pris en charge

Entrez dans la base de données MySQL pour afficher les moteurs de stockage et vous pourrez voir tous les moteurs de stockage pris en charge par la base de données MySQL :

SHOW ENGINES

Actuellement, il existe un moteur que Federated ne prend pas en charge. il suffit de connaître les huit autres. Le stockage de la base de données est correct.

Les moteurs de base de données courants dans MySQL incluent MyISAM, InnoDB et Memory. Alors commençons par comprendre ces trois moteurs.

2. Moteur InnoDB

InnoDB est le moteur par défaut de MySQL, un moteur de stockage qui prend en charge la sécurité des transactions. Les données dans MySQL sont stockées sur le disque physique et le traitement réel des données est effectué en mémoire. Étant donné que la vitesse de lecture et d'écriture du disque est très lente, si le disque est fréquemment lu et écrit à chaque opération, les performances seront très médiocres.

Afin de résoudre les problèmes ci-dessus, InnoDB divise les données en plusieurs pages, en utilisant les pages comme unité de base d'interaction entre le disque et la mémoire. La taille générale de la page est de 16 Ko. Dans ce cas, au moins 1 page de données est lue en mémoire ou 1 page de données est écrite sur le disque à la fois. Améliorez les performances en réduisant le nombre d'interactions entre la mémoire et le disque.

Il s'agit essentiellement d'une idée typique de conception de cache. Généralement, la conception du cache est essentiellement considérée à partir de la dimension temporelle ou de la dimension spatiale :

• Dimension temporelle : si une donnée est utilisée, alors il y a une forte probabilité que il sera réutilisé dans un certain laps de temps. On peut considérer que la mise en cache des données des hotspots fait partie de la mise en œuvre de cette idée.

• Dimension spatiale : si une donnée est utilisée, il y a une forte probabilité que les données stockées à proximité soient également bientôt utilisées. Les pages de données d'InnoDB et le cache de pages du système d'exploitation sont l'incarnation de cette idée.

Ce qui suit est le schéma officiel de la structure du moteur InnoDB, qui est principalement divisé en deux parties : la structure de la mémoire et la structure du disque.

La structure de la mémoire comprend principalement quatre composants : Buffer Pool, Change Buffer, Adaptive Hash Index et Log Buffer.

1.Buffer Pool

Buffer Pool comprend des données, un index, un tampon d'insertion, un index de hachage adaptatif, des informations de verrouillage et un dictionnaire de données. Pool tampon, appelé BP. BP est basé sur la page, avec une taille par défaut de 16 Ko. La couche inférieure de BP utilise une structure de données de liste chaînée pour gérer les pages. Lorsque InnoDB accède aux enregistrements et aux index de table, ils seront mis en cache dans la page Page. Une utilisation ultérieure peut réduire les opérations d'E/S sur le disque et améliorer l'efficacité.

Le pool de tampons est simplement une zone de mémoire qui utilise la vitesse de la mémoire pour compenser l'impact de la lenteur du disque sur les performances de la base de données. Lors de la lecture d'une page dans une base de données, la page lue sur le disque est d'abord stockée dans le pool de tampons. Ce processus est appelé « FIXER » la page dans le pool de tampons. La prochaine fois que la même page sera lue, déterminez d’abord si la page se trouve dans le pool de mémoire tampon. Si elle se trouve dans le pool tampon, la page est dite avoir été atteinte dans le pool tampon. Lisez la page directement. Sinon la page sur le disque est lue. Pour l'opération de modification des pages de la base de données, les pages du pool de mémoire tampon sont d'abord modifiées, puis actualisées sur le disque à une certaine fréquence. Ce qu'il faut noter ici, c'est que l'opération de vidage des pages du pool de mémoire tampon vers le disque n'est pas déclenchée à chaque fois que la page est mise à jour, mais est vidée vers le disque via un mécanisme appelé Checkpoint. Encore une fois, il s'agit d'améliorer les performances globales de la base de données.

Algorithme LUR traditionnel

Le pool de tampons est géré via l'algorithme LRU (Latest recent Used, les moins récemment utilisés), c'est-à-dire que les pages les plus fréquemment utilisées se trouvent au début de la liste LRU et les moins utilisées. les pages sont au début de la liste LRU. À la fin de la liste, lorsque le pool de mémoire tampon ne peut pas stocker la page nouvellement lue, la page à la fin de la liste LRU est d'abord libérée :

(1) La page est déjà dans le pool tampon, donc il suffit de le "déplacer" vers la tête de l'action LRU, mais aucune page n'est éliminée

(2) La page n'est pas dans le pool tampon En plus de l'action de "mettre" la tête LRU ; , l'action "d'éliminer" la page de queue LRU est également effectuée

Mais l'algorithme LUR d'InnoDB Ce n'est pas un algorithme LUR traditionnel ;

Il y a deux problèmes ici :

(1) Échec de la lecture anticipée ;

(2) Pollution du pool tampon

Commençons par comprendre ce qu'est la lecture anticipée :

Lecture anticipée

disque ; lecture et écriture, il ne s'agit pas de lecture à la demande, mais de lecture par page. Au moins une page de données (généralement 4K) est lue à la fois si les données à lire ultérieurement se trouvent dans la page, sur le disque suivant. Les E/S peuvent être omises et l'efficacité peut être améliorée. L'accès aux données suit généralement le principe de « lecture et écriture concentrées ». Lors de l'utilisation de certaines données, il existe une forte probabilité que des données proches soient utilisées. C'est ce qu'on appelle le « principe de localité », qui montre que le chargement précoce est efficace et. peut en effet réduire les E/S du disque.

Échec de lecture anticipée

En raison de la lecture anticipée (Read-Ahead), la page est placée à l'avance dans le pool de tampons, mais à la fin, MySQL ne lit pas les données de la page, ce qui est appelé échec de lecture anticipée.

Pour optimiser l'échec de la lecture anticipée, l'idée est la suivante :

(1) Laisser la page dont la lecture anticipée a échoué rester dans le pool tampon LRU aussi peu de temps que possible

(2) Laisser la page ; qui est réellement lu soit déplacé vers la tête du pool tampon LRU

pour garantir que les données chaudes réellement lues restent dans le pool tampon le plus longtemps possible.

La méthode spécifique est la suivante :

(1) Diviser le LRU en deux parties :

Nouvelle génération (nouvelle sous-liste)

Ancienne génération (ancienne sous-liste)

(2) Les nouvelles et anciennes générations sont connectées à la fin , c'est-à-dire : nouvelle génération La queue de la génération est connectée à la tête de l'ancienne génération

(3) Lorsqu'une nouvelle page (comme une page pré-lue) est ajoutée au pool tampon, elle est seulement ajoutée ; au chef de l'ancienne génération :

Si la donnée est effectivement en lecture (la prélecture est réussie) sera ajoutée au chef de la nouvelle génération

Si la donnée n'est pas lue, elle sera éliminée du pool tampon plus tôt que les « pages de données chaudes » dans la nouvelle génération

Nouveaux et anciens étudiants La version améliorée de LRU ne peut toujours pas résoudre le problème de la pollution des piscines tampons.

2.Log Buffer

Log Buffer est utilisé pour mettre en cache les journaux de rétablissement.

InnoDB a deux journaux très importants : undo log et redo log

(1) Grâce au journal d'annulation, vous pouvez voir les versions antérieures des données, implémenter MVCC ou restaurer des transactions et d'autres fonctions.

(2) Utilisez le journal redo pour garantir la durabilité des transactions.

Le tampon redo log est une zone de stockage mémoire utilisée pour contenir les données à écrire dans un fichier journal sur le disque. La taille du tampon de journal est définie par la variable innodb_log_buffer_size et la taille par défaut est de 16 Mo.

Le contenu du tampon de journal est périodiquement vidé sur le disque. Un tampon de journalisation plus grand permet d'exécuter des transactions volumineuses sans que les données de journalisation ne soient écrites sur le disque avant la validation de la transaction. Par conséquent, si des transactions mettent à jour, insèrent ou suppriment de nombreuses lignes, l'augmentation de la taille du tampon de journal peut économiser les E/S disque.

innodb_flush_log_at_trx_commit : contrôle la façon dont le contenu du tampon de journal est écrit et vidé sur le disque.

innodb_flush_log_at_timeout : contrôlez la fréquence d'actualisation du journal.

Vous devez observer les transactions si les E/S disque entraînent des problèmes de performances, tels que des transactions impliquant de nombreuses entrées BLOB. Le tampon de journal InnoDB est vidé sur le disque chaque fois qu'il est plein, donc augmenter la taille du tampon peut réduire les E/S.

Le nombre par défaut de fichiers journaux est de deux : ib_logfile0 et ib_logfile1.

Le journal a une taille fixe, la taille par défaut dépend de la version de MySQL.

3.Index de hachage adaptatif

Index de hachage adaptatif L'index de hachage adaptatif est une structure de stockage de paires clé-valeur qui stocke les enregistrements où se trouvent les pages chaudes. Le moteur de stockage InnoDB crée automatiquement des index de hachage pour certaines pages en fonction de la fréquence et du modèle d'accès.

L'image ci-dessus représente la différence entre l'index d'arbre B+ et l'index de hachage adaptatif. Désactivez ou activez cette fonctionnalité via le paramètre innodb_adaptive_hash_index, qui est activé par défaut.

4.Change Buffer

Change Buffer : les données dans MySQL sont divisées en deux parties : la mémoire et le disque ; les pages de données chaudes et les pages d'index sont mises en cache dans le pool de tampons pour réduire les lectures sur le disque ; . moyens.

Lorsqu'une page de données doit être mise à jour, mettez-la à jour directement si la page de données est en mémoire. Si la page de données n'est pas en mémoire. Sans affecter la cohérence des données, InooDB mettra en cache ces opérations de mise à jour dans le tampon de modification, de sorte qu'il n'est pas nécessaire de lire cette page de données depuis le disque. Lorsque la requête suivante doit accéder à cette page de données, lisez la page de données en mémoire, puis effectuez les opérations liées à cette page dans le tampon de modification. De cette manière, l'exactitude de la logique des données peut être garantie.

Bien que le nom soit appelé tampon de modification, il s'agit en fait de données qui peuvent être conservées. En d'autres termes, le tampon de modification a une copie en mémoire et sera également écrit sur le disque (ibdata).

 Le processus de fusion des opérations dans le tampon de modification avec la page de données d'origine et d'obtention des derniers résultats est appelé fusion. Les situations suivantes déclencheront la fusion :

• Accédez à cette page de données ;

• Le thread maître en arrière-plan fusionnera régulièrement ;

• Lorsque le pool de tampons de la base de données n'est pas suffisant ;

• Lorsque la base de données est fermée ; normalement ;

• redo Lorsque le journal est plein ;

change buffer signifie que lorsqu'une page d'index ordinaire non unique n'est pas dans le pool de tampons et qu'une opération d'écriture est effectuée sur la page, le tampon de changement d'enregistrement sera Être mis en mémoire tampon en premier, puis l'enregistrement sera modifié lors de la lecture des données futures. La technologie dans le tampon de modification sera fusionnée dans la page de données d'origine. Avant MySQL5.5, il s'appelait tampon d'insertion (tampon d'insertion), et il n'était optimisé que pour l'insertion ; maintenant, il est également valable pour la suppression et la mise à jour, et il est appelé tampon d'écriture (tampon de changement).

Apprentissage recommandé : Tutoriel vidéo mysql

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!