2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
D'une manière générale, MySQL peut être divisé en deux couches
mysql -h$ip -P$port -u$user -p
Le mysql dans la commande de connexion est un outil client utilisé pour établir une connexion avec le serveur.Après avoir terminé la négociation TCP classique, le connecteur
Il est sur le point de commencer à authentifier votre identité. À ce moment-là, le nom d'utilisateur et le mot de passe que vous avez saisis seront utilisés.
Si le client reste inactif trop longtemps, le connecteur le déconnectera automatiquement. Ce temps est contrôlé par le paramètre wait_timeout et la valeur par défaut est de 8 heures.
Si le client envoie à nouveau une requête après la déconnexion de la connexion, il recevra un rappel d'erreur : Lost connection to MySQL server during query . Si vous souhaitez continuer à ce moment-là, vous devez vous reconnecter puis exécuter la requête.
Dans la base de données, une connexion longue signifie qu'une fois la connexion réussie, si le client continue de faire des requêtes, la même connexion sera toujours utilisée. Une connexion courte signifie que la connexion est déconnectée après l'exécution de quelques requêtes et qu'une nouvelle est rétablie pour la requête suivante.
Le processus d'établissement d'une connexion est généralement compliqué, je vous suggère donc d'essayer de minimiser les actions d'établissement d'une connexion pendant l'utilisation, c'est-à-dire d'essayer d'utiliser des connexions longues.
Mais après avoir utilisé de longues connexions, vous constaterez peut-être que parfois la mémoire occupée par MySQL augmente très rapidement.La mémoire temporairement utilisée par MySQL lors de l'exécution est gérée dans l'objet de connexion. . Ces ressources seront libérées lorsque la connexion sera déconnectée.Donc siL'accumulation de connexions longues peut entraîner une utilisation excessive de la mémoire., a été tué de force par le système (MOO). À en juger par le phénomène, MySQL a redémarré anormalement.
Comment résoudre ce problème? Vous pouvez envisager les deux options suivantes.
mysql_reset_connection pour réinitialiser les ressources de connexion. Ce processus ne nécessite pas de reconnexion ni de vérification des autorisations, mais restaurera la connexion à l'état où elle vient d'être créée.Une fois que MySQL a reçu une requête de requête, il ira d'abord dans le cache de requêtes pour voir si cette instruction a déjà été exécutée. Les instructions précédemment exécutées et leurs résultats peuvent être mis en cache directement en mémoire sous la forme de paires clé-valeur. La clé est l'instruction de requête et la valeur est le résultat de la requête. Si votre requête parvient à trouver la clé directement dans ce cache, alors la valeur sera renvoyée directement au client.
Si l'instruction n'est pas dans le cache de requêtes, la phase d'exécution se poursuit. Une fois l'exécution terminée, les résultats de l'exécution seront stockés dans le cache des requêtes. Vous pouvez voir que si la requête atteint le cache, MySQL peut renvoyer directement le résultat sans effectuer d'opérations complexes ultérieures, ce qui est très efficace.
Mais la plupart du temps je le feraiIl est recommandé de ne pas utiliser la mise en cache des requêtes ,pourquoi? Parce que la mise en cache des requêtes fait souvent plus de mal que de bien.
Le cache de requêtes est invalidé très fréquemment. Tant qu'une table est mise à jour, tous les caches de requêtes sur cette table seront effacés. Il est donc possible que vous ayez pris la peine de sauvegarder les résultats et qu'avant même de les utiliser, ils aient été effacés par une mise à jour. Pour les bases de données soumises à une forte pression de mise à jour, le taux de réussite du cache de requêtes sera très faible. A moins que votre entreprise ne dispose d’un tableau statique qui ne sera mis à jour qu’une fois de longue durée. Par exemple, s'il s'agit d'une table de configuration système, la requête sur cette table convient au cache de requêtes.
Heureusement, MySQL propose également cette méthode « d'utilisation à la demande ». Vous pouvez définir le paramètre query_cache_type sur DEMAND afin que le cache de requêtes ne soit pas utilisé pour les instructions SQL par défaut. Pour les instructions pour lesquelles vous êtes sûr de vouloir utiliser le cache de requêtes, vous pouvez utiliser SQL_CACHE pour le spécifier explicitement, comme l'instruction suivante :
select SQL_CACHE * from T where ID=10；
il faut en être conscient,La version MySQL 8.0 supprime directement toute la fonction de cache de requêtes, ce qui signifie que cette fonction ne sera plus disponible à partir de la version 8.0.
Si le cache de requêtes n’est pas atteint, l’exécution réelle de l’instruction commence. Tout d’abord, MySQL doit savoir ce que vous voulez faire, il doit donc analyser l’instruction SQL.
Je ne sais pas si vous vous souvenez encore de l'article "Kong Yiji". Le directeur de l'hôtel possède un tableau rose spécialement utilisé pour enregistrer les dossiers de crédit des clients. S'il n'y a pas beaucoup de gens qui paient à crédit, il peut alors écrire le nom et le compte du client au tableau. Mais s'il y a trop de personnes ayant des comptes de crédit, il y aura toujours des moments où le tableau des fans ne pourra pas les suivre. À ce moment-là, le commerçant doit disposer d'un grand livre spécialement pour enregistrer les comptes de crédit.
Si quelqu’un souhaite rembourser un crédit ou une dette, le commerçant a généralement deux possibilités :
Lorsque les affaires sont en plein essor et que le comptoir est occupé, le commerçant choisira certainementle dernier , car la première opération est trop gênante. Tout d'abord, vous devez trouver l'enregistrement du compte de crédit total de cette personne. Pensez-y, il y a des dizaines de pages densément remplies. Pour trouver le nom, le commerçant devra peut-être mettre des lunettes de lecture et chercher lentement, il sortira le boulier pour calculer, et enfin réécrira le résultat. le grand livre.
Il est difficile de penser à tout ce processus. En revanche, il est plus facile de l’écrire d’abord sur le tableau rose. Pensez-y, si le commerçant n'a pas l'aide du tableau rose, il doit retourner le grand livre à chaque fois qu'il enregistre les comptes, l'efficacité n'est-elle pas insupportablement faible ?
De même, ce problème existe également dans MySQL. Si chaque opération de mise à jour doit être écrite sur le disque et que le disque doit également trouver l'enregistrement correspondant avant la mise à jour, le coût d'E/S et de recherche de l'ensemble du processus sera très élevé. Afin de résoudre ce problème, les concepteurs de MySQL ont utilisé une idée similaire au tableau rose du commerçant d'un hôtel pour améliorer l'efficacité des mises à jour.
L'ensemble du processus de coopération entre le tableau rose et le grand livre est en fait ce qui est souvent mentionné dans MySQL. WAL technologie,WAL Le nom complet estWrite-Ahead Logging, le point clé estÉcrivez d'abord le journal, puis écrivez sur le disque, c'est-à-dire écrivez d'abord le tableau rose, puis écrivez le livre de comptes lorsque vous n'êtes pas occupé.
Plus précisément, lorsqu'un enregistrement doit être mis à jour, le moteur InnoDB écrira d'abord l'enregistrement dans le journal redo (tableau rose) et mettra à jour la mémoire. À ce moment, la mise à jour est terminée. Dans le même temps, le moteur InnoDB mettra à jour l'enregistrement des opérations sur le disque au moment approprié, et cette mise à jour est souvent effectuée lorsque le système est relativement inactif, tout comme ce que fait le commerçant après la fermeture.
S'il n'y a pas beaucoup de comptes créditeurs aujourd'hui, le commerçant peut attendre l'heure de fermeture pour trier les articles. Mais que devons-nous faire s’il y a beaucoup de comptes créditeurs un certain jour et que le tableau rose est plein ? À cette époque, le commerçant devait abandonner son travail, mettre à jour certains des enregistrements de crédit du tableau rose dans le grand livre, puis effacer ces enregistrements du tableau rose pour faire de la place pour de nouveaux comptes.
De même, le journal redo d'InnoDB a une taille fixe. Par exemple, il peut être configuré comme un ensemble de 4 fichiers, chaque fichier mesure 1 Go. Ensuite, ce « tableau rose » peut enregistrer un total de 4 Go d'opérations. Commencez à écrire depuis le début, puis revenez au début pour écrire en boucle, comme le montre l'image ci-dessous.
write pos est la position de l'enregistrement en cours. Il recule lors de l'écriture. Après avoir écrit à la fin du fichier n° 3, il revient au début du fichier n° 0. Le point de contrôle est la position actuelle à effacer, et il avance également et boucle. Avant d'effacer l'enregistrement, l'enregistrement doit être mis à jour dans le fichier de données.
L'espace entre la position d'écriture et le point de contrôle est la partie vide du « tableau rose » qui peut être utilisée pour enregistrer de nouvelles opérations. Si la position d'écriture rattrape le point de contrôle, cela signifie que le "tableau rose" est plein et qu'aucune nouvelle mise à jour ne peut être effectuée pour le moment. Vous devez d'abord arrêter et effacer certains enregistrements pour avancer le point de contrôle.
Avec le redo log, InnoDB peut garantir que même si la base de données redémarre anormalement, les enregistrements précédemment soumis ne seront pas perdus. Cette capacité est appelée.crash-safe。
Pour comprendre le concept de sécurité en cas de crash, pensez à notre précédent exemple de dossier de crédit. Tant que le dossier de crédit est enregistré sur le tableau rose ou écrit sur le grand livre, même si le commerçant l'oublie plus tard, par exemple en suspendant soudainement son activité pendant quelques jours, il peut toujours clarifier le compte de crédit grâce aux données du grand livre et tableau rose après la reprise des activités.
Comme nous l'avons dit précédemment, MySQL dans son ensemble comprend en réalité deux parties : l'une est la couche serveur, qui s'occupe principalement des tâches au niveau fonctionnel de MySQL ; l'autre est la couche moteur, qui est responsable des questions spécifiques liées au stockage.Le tableau rose dont nous parlions plus hautredo log est un journal unique au moteur InnoDB,et La couche Serveur possède également son propre journal, appelé binlog (journal d'archive)。
Je pense que vous vous demanderez pourquoi y a-t-il deux journaux ?
Parce qu'il n'y avait pas de moteur InnoDB dans MySQL au début. Le propre moteur de MySQL est MyISAM, mais MyISAM n'a pas de fonctionnalités de sécurité contre les pannes et les journaux binlog ne peuvent être utilisés qu'à des fins d'archivage. InnoDB a été introduit dans MySQL sous la forme d'un plug-in par une autre société. Étant donné que le fait de s'appuyer uniquement sur binlog n'a pas de capacités de sécurité contre les crashs, InnoDB utilise un autre système de journalisation, à savoir le redo log, pour obtenir des capacités de sécurité contre les crashs.
Ces deux journaux présentent les trois différences suivantes.
Avec une compréhension conceptuelle de ces deux journaux, examinons les processus internes de l'exécuteur et du moteur InnoDB lors de l'exécution de cette simple instruction de mise à jour.
Ici, je donne l'organigramme d'exécution de cette instruction de mise à jour. La case lumineuse dans la figure indique qu'elle est exécutée dans InnoDB, et la case sombre indique qu'elle est exécutée dans l'exécuteur.
processus d'exécution de l'instruction de mise à jour
Vous avez peut-être remarqué que les trois dernières étapes semblent un peu « circulaires ». L'écriture du redo log est divisée en deux étapes : préparer et valider. Il s'agit d'un « commit en deux phases ».
Pourquoi faut-il une « soumission en deux phases » ?Ceci permet de faire la différence entre les deux journauxlogiquement cohérent . Pour expliquer ce problème, nous devons commencer par la question du début de l'article : Comment restaurer la base de données à l'état d'une seconde en un demi-mois ?
Comme nous l'avons déjà dit, binlog enregistrera toutes les opérations logiques et adoptera la forme d'une « écriture d'ajout ». Si votre administrateur de base de données promet qu'il peut être restauré dans un délai d'un demi-mois, le système de sauvegarde enregistrera définitivement tous les journaux binaires au cours du dernier demi-mois et le système effectuera des sauvegardes régulières de l'ensemble de la base de données. Le « régulier » dépend ici de l'importance du système, qui peut être une fois par jour ou une fois par semaine.
Lorsque vous devez restaurer à une seconde spécifiée, par exemple, à deux heures de l'après-midi un jour, vous constatez qu'une table a été accidentellement supprimée à midi et que vous devez récupérer les données, vous pouvez procéder comme suit :
D'accord, après avoir parlé du processus de récupération des données, revenons et expliquons pourquoi le journal nécessite une « validation en deux phases ». Ici, autant utiliser la preuve par contradiction pour expliquer.
Étant donné que le redo log et le binlog sont deux logiques indépendantes, si la validation en deux phases n'est pas utilisée, soit le redo log doit être écrit en premier, puis le binlog doit être écrit, soit l'ordre inverse doit être adopté. Voyons quels sont les problèmes liés à ces deux méthodes.
Utilisez toujours l'instruction de mise à jour précédente comme exemple. Supposons que la valeur du champ c dans la ligne actuelle avec ID=2 soit 0, et supposons que lors de l'exécution de l'instruction de mise à jour, un crash se produise après l'écriture du premier journal mais avant l'écriture du deuxième journal. Que se passera-t-il ?
Vous pourriez vous demander : cette probabilité est-elle très faible ? Il n’existe aucune situation dans laquelle la bibliothèque temporaire doit être restaurée à tout moment.
En fait non, ce processus n’est pas seulement nécessaire pour récupérer des données après une mauvaise opération. Lorsque vous avez besoin d'étendre la capacité, c'est-à-dire lorsque vous devez créer davantage de bases de données de sauvegarde pour augmenter la capacité de lecture du système, la pratique courante consiste désormais à utiliser une sauvegarde complète et à appliquer binlog pour y parvenir. Cette "incohérence" entraînera votre présence. est une incohérence entre les bases de données maître et esclave en ligne.
En termes simples, redo log et binlog peuvent être utilisés pour représenter l'état de validation d'une transaction, etLa soumission en deux phases vise à maintenir la cohérence logique des deux États.。
Il se consacre à la recherche technologique depuis plus de 30 ans et maîtrise divers langages tels que java, linux, javascript, php, css, etc. Il a apporté de nombreuses contributions dans le domaine de l'open source. station de documentation pour les développeurs pour partager certains problèmes de développement technologique pour référence future.
