Les likes sont quand même de rigueur, au cas où il y aurait un beau mec devant l'écran, juste comme ça ! ! ! !
Auteur : M. Raymon dans Source Code Times
dire d'avance
Mysql, en tant qu'excellent système de gestion de base de données largement utilisé, est presque un élément indispensable du développement quotidien de nombreux ingénieurs Java. Qu'il s'agisse de stocker des données massives ou de récupérer et de gérer efficacement des données, Mysql joue un rôle important. Cependant, en plus d'utiliser Mysql pour le développement quotidien, comprenons-nous vraiment son architecture sous-jacente et le processus de conception et de mise en œuvre ? Ce blog vous emmènera explorer en profondeur le processus de conception et de mise en œuvre de l'architecture sous-jacente de Mysql, vous aidant à mieux comprendre et appliquer ce puissant système de base de données. Découvrons ensemble le mystère de la couche inférieure de Mysql et explorons ses mystères.
1. A quoi ressemble Mysql à vos yeux ?
MySQL, aux yeux de la plupart des ingénieurs Java ordinaires, est souvent considéré comme un outil de stockage et de manipulation de données. Nous l'utilisons souvent pour créer des bases de données, créer des tables et des index, afin d'ajouter, de supprimer, de modifier et d'interroger des données. Ces méthodes d'utilisation de base sont devenues des opérations de routine lorsque nous traitons avec MySQL dans notre travail quotidien. (Comme l'image ci-dessous)
Cependant, dans le développement quotidien, nous nous concentrons souvent uniquement sur la façon d'utiliser correctement MySQL pour les opérations de données, et avons rarement une compréhension approfondie de l'architecture sous-jacente et des principes de mise en œuvre de MySQL. Nous en savons peut-être peu sur les mécanismes sous-jacents tels que les moteurs de stockage, les optimiseurs de requêtes et la gestion des transactions, et avons une connaissance limitée de la façon d'optimiser les performances, d'assurer la cohérence des données, ainsi que la sauvegarde et la restauration.
Pour cette raison, il est très important pour nous de comprendre le processus de conception et de mise en œuvre de l'architecture MySQL sous-jacente. Cela peut non seulement nous aider à mieux comprendre le mécanisme interne de MySQL, mais aussi à améliorer l'efficacité et la qualité de notre travail. Dans le contenu suivant, nous aborderons en profondeur les différents composants et technologies de l'architecture sous-jacente de MySQL, dans l'espoir de vous apporter une connaissance plus approfondie et plus complète de MySQL. Dévoilons le voile sous-jacent de MySQL et explorons ses mystères
2. Comment le système Java se connecte-t-il à Mysql ?
En Java, la connexion à une base de données MySQL nécessite généralement JDBC (Java Database Connectivity). JDBC est un ensemble d'API fournies par Java pour accéder aux bases de données. Il fournit une interface standard qui nous permet d'interagir avec diverses bases de données via du code Java.
Pour vous connecter à la base de données MySQL, vous devez d'abord vous assurer que la base de données MySQL a été installée dans le système et que le pilote MySQL JDBC approprié a été importé dans le projet Java. Le pilote Mysql construit pour nous un pont entre le système Java et la base de données Msyql :
Par conséquent, lorsque nous implémentons du code métier, si nous devons exécuter des instructions SQL associées, le pilote Mysql peut nous aider à transmettre les instructions SQL à la base de données Mysql pour exécution : alors réfléchissons à une question, un système Java peut-il uniquement
suivre la base de données établit une connexion ? Ce n'est certainement pas possible, car nous devons comprendre une vérité. Supposons que nous développions un système Web en Java et que nous le déployions dans Tomcat, alors Tomcat lui-même doit avoir plusieurs threads pour traiter plusieurs requêtes simultanément. Regardons l'image ci-dessous : Par conséquent
, lorsqu'il y a plusieurs demandes commerciales, nous pouvons établir une connexion à la base de données pour chaque demande pour une utilisation distincte, comme suit : Mais 
dans un scénario à haute simultanéité, si chaque thread Tomcat accède à la base de données. Est-il possible de se connecter à une base de données, d'exécuter un instruction SQL, puis détruire la connexion ? Il peut y avoir des centaines de threads exécutant fréquemment ce processus. Cette approche n'est pas recommandée. L'établissement d'une connexion à la base de données prend du temps à chaque fois. Lorsque la connexion est établie et que l'instruction SQL est exécutée, la connexion est détruite et la connexion est rétablie. C'est très inefficace.
Par conséquent, nous devons introduire le concept de pool de connexions pour résoudre ce problème. Le pool de connexions gère un ensemble de connexions de base de données réutilisables et gère efficacement les connexions. Lorsque le thread Tomcat doit accéder à la base de données, il peut obtenir une connexion disponible à partir du pool de connexions et renvoyer la connexion au pool de connexions après l'exécution. Cela peut réduire la création et la destruction fréquentes de connexions et améliorer les performances. Comme suit:
3. Pourquoi Mysql a-t-il également besoin d'un pool de connexion ?
Vous savez, quand vous allez à la banque pour faire des affaires, vous devez parfois faire la queue ? Ce serait une perte de temps et de ressources de supposer que tout le monde doit attendre que le personnel de la banque fasse les affaires à sa place, n'est-ce pas ? Le pool de connexions MySQL est comme un système de file d'attente pour les transactions bancaires, ce qui nous aide à gérer et à utiliser plus efficacement les connexions à la base de données.
-
Améliorer l'efficacité de la connexion : dans MySQL, certains travaux préparatoires sont nécessaires pour établir une connexion à la base de données, tout comme le personnel de la banque doit faire quelques préparatifs avant de traiter les affaires. Si la connexion est recréée à chaque fois, elle sera très inefficace, tout comme tout le monde doit se rendre à la banque pour faire la queue pour obtenir un numéro et gérer les affaires. Le pool de connexions créera certaines connexions à l'avance, tout comme la banque prépare plusieurs fenêtres à l'avance pour le traitement des affaires, de sorte qu'une seule connexion disponible peut être obtenue à partir du pool de connexions, ce qui réduit le temps d'attente et améliore l'efficacité de la connexion.
-
Économisez les ressources système : la connexion à la base de données est une ressource limitée, tout comme le personnel d'une banque est limité. Si tout le monde utilise un membre du personnel pour gérer les affaires, la banque sera rapidement paralysée. Le pool de connexions peut gérer et contrôler le nombre de connexions, similaire au nombre de fenêtres de contrôle bancaire, pour s'assurer que trop de connexions ne seront pas créées, évitant ainsi le gaspillage des ressources de la base de données et du serveur.
-
Simplifier la gestion des connexions : La mise en commun des connexions nous permet de gérer plus facilement les connexions, tout comme le système de file d'attente d'une banque permet au personnel de la banque de se concentrer sur les affaires des clients. Grâce au pool de connexions, nous n'avons pas besoin de créer et de libérer manuellement la connexion, il suffit d'obtenir la connexion du pool de connexions et de l'utiliser, puis de la renvoyer au pool de connexions une fois terminée. Cela simplifie le travail de gestion des connexions et améliore l'efficacité du développement. En résumé, le pool de connexions MySQL est comme un système de file d'attente bancaire, qui peut améliorer l'efficacité de la connexion, économiser les ressources système, gérer la fiabilité de la connexion et simplifier la gestion des connexions. Le pool de connexions joue un rôle important dans les opérations de base de données à haute simultanéité, nous aidant à nous connecter et à interagir avec la base de données MySQL de manière plus efficace et plus pratique.
4. Comment Mysql gère-t-il les demandes de connexion ?
Lorsque Mysql reçoit une demande de connexion réseau, comment traite-t-il la demande et comment exécuter finalement le SQL, examinons les étapes de l'ensemble du lien de processus.
d'abord:
- La connexion réseau doit être affectée à un thread pour le traitement, et un thread surveille la demande et lit les données de la demande, comme la lecture et l'analyse d'une instruction SQL envoyée par le système Java à partir de la connexion réseau
. - Un composant est fourni à l'intérieur de Mysql : SQL Interface (SQL Interface), qui est utilisé pour exécuter spécifiquement des instructions SQL
- Ensuite, utilisez l'optimiseur de requête : sélectionnez le chemin de requête optimal à exécuter, fonction : générez une arborescence de chemin de requête pour les instructions SQL complexes écrites par vous avec des dizaines de lignes, des centaines de lignes ou même des milliers de lignes, puis sélectionnez une requête optimale à partir de celle-ci. chemin de sortie.
- Call the executor : appelez l'interface du moteur de stockage selon le plan d'exécution
- Appelez l'interface du moteur de stockage pour exécuter réellement l'instruction SQL. Fonction : l'exécuteur appellera l'interface du moteur de stockage selon un certain ordre et selon le plan d'exécution sélectionné par l'optimiseur, et exécutera la logique de l'instruction SQL.
- Moteur de stockage : gérer et stocker des données, prendre en charge une variété de moteurs de stockage tels que : InnoDB, MyISAM, Memory, nous pouvons choisir le moteur de stockage à utiliser pour être responsable de l'exécution d'instructions SQL spécifiques. Maintenant, MySQL utilise généralement le moteur de stockage InnoDB par défaut.
Si vous êtes intéressé par l'ensemble du processus d'exécution ci-dessus, vous pouvez l'étudier en profondeur, et cet article n'introduira pas les détails. Analysons comment le moteur de stockage InnoDB gère et stocke nos données.
5. Structure mémoire importante d'InnoDB : pool de mémoire tampon
Dans le moteur de stockage InnoDB, il y a un composant très important dans la mémoire, qui est le pool de mémoire tampon (BufferPool), qui mettra en cache beaucoup de données, de sorte que lorsque vous interrogerez plus tard, si vous avez des données dans le pool de mémoire tampon, juste Vous n'avez pas besoin de vérifier le disque, regardons l'image ci-dessous.
Par exemple, l'instruction SQL : update users set name='xxx' where id=1, par exemple, pour la ligne de données "id=1", il va d'abord vérifier si la ligne de données "id=1" est dans le pool de mémoire tampon, s'il n'y est pas, il sera chargé directement du disque dans le pool de mémoire tampon, puis un verrou exclusif sera ajouté à cette ligne d'enregistrements.
Le pool de mémoire tampon utilise l'algorithme LRU (Least Récemment Utilisé) pour gérer les pages de données en mémoire. Lorsqu'une requête doit accéder à des données, InnoDB vérifie d'abord si la page de données correspondante existe dans le pool de mémoire tampon. S'il est présent, il récupère les données directement à partir de la mémoire au lieu de les lire à partir du disque, ce qui améliore considérablement les performances des requêtes. Si la page de données n'est pas dans le pool de mémoire tampon, InnoDB la lira dans le pool de mémoire tampon et la conservera en mémoire pour les requêtes ultérieures.
En configurant correctement la taille du pool de mémoire tampon, les pages de données fréquemment utilisées peuvent toujours être conservées en mémoire, ce qui améliore l'efficacité des requêtes. Les pools de mémoire tampon plus grands conviennent généralement aux serveurs disposant de grandes quantités de mémoire
6.undo log file : pour que les données mises à jour puissent être annulées
Les fichiers journaux d'annulation sont utilisés pour enregistrer les opérations des transactions en cours dans la base de données afin de fournir des données d'annulation lorsqu'une transaction doit être annulée. Lorsqu'une opération de mise à jour, de suppression ou d'insertion se produit, le moteur InnoDB enregistre les informations pertinentes dans le fichier journal d'annulation.
Lorsqu'une transaction doit être annulée, le moteur InnoDB utilise le journal d'annulation pour restaurer les données à l'état avant le début de la transaction. Il annule les modifications apportées aux données en inversant l'opération et restaure les données à leur état précédent.
Lorsque nous chargeons l'enregistrement à mettre à jour depuis le fichier disque vers le pool de mémoire tampon, que nous le verrouillons en même temps et que nous écrivons l'ancienne valeur avant la mise à jour dans le fichier journal d'annulation, nous pouvons officiellement commencer à mettre à jour l'enregistrement. les enregistrements dans le pool de mémoire tampon seront mis à jour en premier, et les données à ce moment sont des données modifiées.
La soi-disant mise à jour des données dans le pool de mémoire tampon signifie ici changer le champ de nom de la ligne de données "id=1" dans la mémoire
en "xxx":
7. Redo log files : assurez la cohérence et la persistance des données
Imaginons maintenant que si l'opération de modification dans la figure ci-dessus a été écrite dans le cache, mais qu'elle n'a pas été synchronisée sur le disque pour une persistance future ; à ce moment, la machine msyql est en panne et raccroche, alors les données dans le cache sera inévitablement Si elle est perdue, les données mises à jour seront également perdues. Ainsi, afin d'assurer la cohérence et la pérennité des données Mysql, le moteur innodb introduit des fichiers redo log.
Le Redo Log est un journal physique qui sert principalement à enregistrer les opérations de modification effectuées sur la base de données avant que la transaction ne soit validée. Lorsque la base de données tombe en panne ou tombe en panne, le journal de rétablissement peut être utilisé pour restaurer le dernier état soumis afin d'assurer la persistance des données.
Le rôle de Redo Log se reflète principalement dans les deux aspects suivants :
- Récupération de données : lorsque la base de données échoue, les opérations de modification non validées peuvent être réappliquées à la base de données via Redo Log, restaurant ainsi le dernier état soumis.
- Améliorer les performances : en enregistrant les opérations de modification dans le journal de rétablissement, les opérations d'E/S de disque peuvent être converties en opérations d'écriture séquentielle, ce qui améliore considérablement les performances d'écriture de la base de données.
Par conséquent, lorsque l'opération de mise à jour est exécutée, Mysql écrira la modification dans la mémoire dans un Redo Log Buffer, qui est également un tampon dans la mémoire et est utilisé pour stocker le journal redo. Le soi-disant journal de rétablissement sert à enregistrer les modifications que vous avez apportées aux données, telles que le changement de la valeur du champ de nom en xxx pour l'enregistrement "id=10", c'est un journal. Comme indiqué dans la figure ci-dessous :
Remarques : innodb_log_buffer_size : spécifie la taille de la mémoire tampon de Redo Log, la valeur par défaut est de 8 Mo. Une valeur plus élevée
peut réduire les opérations d'actualisation fréquentes et améliorer les performances, mais elle consommera également plus de mémoire.
8. Soumettre la transaction : redo log flushing
Lorsque la transaction est validée, les données dans la zone de cache du redolog seront vidées sur le disque. La perte de données est-elle donc importante à ce stade ?
En fait, cela n'a pas d'importance, car si vous n'avez pas soumis de transaction pour une instruction de mise à jour, cela signifie qu'elle n'a pas réussi à s'exécuter. À ce stade, bien que le temps d'arrêt de MySQL ait entraîné la perte de toutes les données en mémoire, vous constaterez que les données sur le disque sont toujours dans leur état d'origine.
Trois stratégies pour écrire les journaux redo sur le disque
La stratégie de vidage est configurée via innodb_flush_log_at_trx_commit, qui a plusieurs options :
- Si la valeur du paramètre est 0, le journal de rétablissement n'entre pas sur le disque, ce qui signifie que le journal de rétablissement n'est pas vidé sur le disque, c'est-à-dire la stratégie d'écriture asynchrone. Lorsqu'une transaction est validée, l'opération de modification du journal redo sera uniquement écrite dans le cache de pages du système d'exploitation et ne sera pas immédiatement vidée sur le disque. Cela offre les meilleures performances d'écriture, mais peut entraîner un certain degré de perte de données en cas de panne ou de défaillance de la base de données.
- La valeur du paramètre est 1 et le journal de rétablissement est envoyé sur le disque [valeur par défaut] signifie que le journal de rétablissement est vidé sur le disque de manière synchrone. Lorsque la transaction est validée, l'opération de modification du journal redo sera écrite sur le disque immédiatement et attendra la fin de l'opération IO. Tout en assurant la persistance des données, cela aura également un certain impact sur les performances. Il s'agit du paramètre le plus couramment utilisé et il convient à la plupart des scénarios d'application.
- La valeur du paramètre est 2 et le journal de rétablissement est entré dans le cache du système d'exploitation.
Indique que l'opération de modification du journal redo est écrite sur le disque chaque fois qu'une transaction est validée, mais qu'elle n'attend pas la fin de l'opération IO. Lorsqu'une transaction est validée, le journal de rétablissement est d'abord écrit dans le cache de page du système d'exploitation, puis le thread d'arrière-plan vide les données de manière asynchrone sur le disque. Cette configuration peut offrir de meilleures performances et un certain degré de protection des données, mais il existe toujours des risques.
Sélection de la stratégie de vidage
La sélection de la valeur innodb_flush_log_at_trx_commit appropriée dépend des exigences en matière de persistance et de performances des données. Il peut être défini sur 1 si les exigences de persistance des données sont très élevées. Si l'exigence de performances est élevée et qu'un certain degré de perte de données est acceptable, il peut être défini sur 0. Si vous recherchez de meilleures performances tout en garantissant un certain degré de protection des données, vous pouvez choisir de le définir sur 2.
Vous pouvez ajuster la valeur innodb_flush_log_at_trx_commit en modifiant les réglages des paramètres dans le fichier de configuration MySQL et redémarrer le service MySQL pour qu'il prenne effet.
Nous recommandons généralement de le régler sur 1. C'est-à-dire que lors de la validation d'une transaction, le journal de rétablissement doit être vidé dans le fichier disque. Cela peut strictement garantir qu'une fois la transaction validée, les données ne seront jamais perdues, car il existe des journaux de rétablissement dans le fichier disque pour restaurer toutes les modifications que vous avez apportées.
9. Qu'est-ce que binlog exactement
En fait, le journal de rétablissement que nous avons mentionné précédemment est une sorte de journal de rétablissement qui est biaisé vers la nature physique, car il enregistre quelque chose comme ceci, "quelle modification a été apportée à quel enregistrement dans quelle page de données".
Et le journal de rétablissement lui-même est quelque chose d'unique au moteur de stockage InnoDB. Le binlog est appelé un journal d'archivage, qui enregistre un journal biaisé vers la logique, similaire à "mettre à jour une ligne de données avec id=1 dans la table des utilisateurs, quelle est la valeur après la mise à jour", binlog n'est pas un stockage InnoDB engine Le fichier journal unique est un fichier journal appartenant au serveur mysql lui-même. Par conséquent, lorsqu'une transaction est validée, binlog sera écrit en même temps : 
Analyse de la stratégie de vidage du journal binlog
Pour les journaux binlog, il existe en fait différentes stratégies de vidage. Il existe un paramètre sync_binlog qui peut contrôler la stratégie de vidage du journal binlog, et sa valeur par défaut la valeur est 0 , lorsque vous écrivez le binlog sur le disque, il n'entre pas directement dans le fichier disque, mais entre dans le cache mémoire du système d'exploitation. Donc, comme pour l'analyse précédente, si la machine est en panne à ce moment, alors votre journal binlog dans le cache de l'os sera perdu :
si vous définissez le paramètre sync_binlog sur 1, alors à ce moment-là, il sera forcé de soumettre la transaction. Le binlog est écrit directement sur le fichier disque, donc une fois la transaction validée de cette manière, même si la machine tombe en panne, le binlog sur le disque ne sera pas perdu.
Soumission complète des transactions basée sur binlog et redo log
Lorsque nous écrivons le fichier binlog sur le fichier disque, la soumission finale de la transaction sera terminée. À ce moment, le nom du fichier binlog correspondant à cette mise à jour et l'emplacement du journal binlog mis à jour dans le fichier seront écrits dans le journal de rétablissement. Accédez au fichier journal et écrivez une marque de validation dans le fichier journal de journalisation en même temps. Après avoir terminé ce sujet, la soumission de la transaction est enfin terminée. Regardons le diagramme ci-dessous :
Quelle est l'importance d'écrire la marque de validation dans le journal de rétablissement à la dernière étape ?
Pour que le journal redo reste cohérent avec le journal binlog, la marque de validation finale de la transaction doit être écrite dans le journal redo, puis la transaction est validée avec succès à ce moment, et il y a un journal correspondant à cette mise à jour dans le journal redo, et là est aussi un log dans le binlog Le log correspondant à la seconde mise à jour, redo log et binlog sont parfaitement cohérents
Le thread d'E/S d'arrière-plan vide de manière aléatoire les données modifiées après la mise à jour de la mémoire sur le disque
MySQL a un thread d'E/S d'arrière-plan, qui va vider de manière aléatoire les données sales modifiées dans le pool de mémoire tampon vers le fichier de données sur le disque à un certain moment dans le futur. Voyons la figure suivante : dans votre thread d'E/S Avant de vider
le données sur le disque, peu importe même si mysql plante, car après le redémarrage, il restaurera la modification apportée par la transaction soumise auparavant en fonction du journal de rétablissement de la mémoire, puis attendra le bon moment, l'IO thread fera naturellement cette modification. Les données finales sont vidées dans le fichier de données sur le disque.
10. Résumé
Le moteur de stockage InnoDB contient principalement des données mises en cache en mémoire, telles que le pool de mémoire tampon et le tampon de journalisation, et contient également des fichiers journaux d'annulation, des fichiers journaux de rétablissement, etc., et le serveur mysql lui-même possède également des fichiers journaux binlog.
Lorsque vous effectuez une mise à jour, chaque instruction SQL correspondra à la modification des données mises en cache dans le pool de mémoire tampon, à l'écriture du journal d'annulation et à l'écriture du tampon de journalisation ; mais lorsque vous soumettez la transaction, le journal de rétablissement sera définitivement vidé sur le disque , le binlog est vidé sur le disque et la marque de validation de la transaction dans le journal de rétablissement est terminée ; enfin, le thread d'E/S d'arrière-plan videra de manière aléatoire les données modifiées du pool de mémoire tampon sur le disque.
A la fin de l'article, les likes sont toujours de rigueur, au cas où il y aurait un beau mec devant l'écran, juste comme ça ! ! ! !
