Comment SQL est exécuté dans la base de données MySQL-tutoriel mysql-php.cn

Comment SQL est exécuté dans la base de données MySQL

coldplay.xixi

Libérer： 2020-11-09 17:20:22

original

1854 Les gens l'ont consulté

Aujourd'hui, jetons un coup d'œil au processus d'exécution d'une instruction de mise à jour avec la colonne tutoriel vidéo mysql.

Comment SQL est exécuté dans la base de données MySQL

Un ensemble de processus d'exécution pour les instructions de requête et les instructions de mise à jour passera également par les mêmes étapes. Ci-dessous, nous comparons ceux de la. dernier article Jetons un bref coup d'œil à l'image :

Tout d'abord, vous devez vous connecter à la base de données avant d'exécuter l'instruction. C'est le travail du connecteur dans. la première étape.Nous avons également dit précédemment : Lorsqu'une table est mise à jour, le cache de requêtes associé à cette table deviendra invalide, nous ne recommandons donc généralement pas le cache de requêtes d'octobre.

Ensuite, l'analyseur procédera à l'analyse syntaxique et à l'analyse lexicale. Après avoir su qu'il s'agit d'une instruction de mise à jour, l'optimiseur décide quel index utiliser, puis l'exécuteur est responsable de l'exécution spécifique. ligne, puis effectuez la mise à jour.

Différent de la mise à jour de l'instruction de requête, le processus de mise à jour implique également deux journaux importants. Nous l'avons également introduit dans l'article précédent. Si vous êtes intéressé, vous pouvez trouver l'article de la semaine dernière "Deux journaux importants de MySQL". . "Un système de journalisation", je ne le présenterai pas beaucoup ici.

Ce qui suit est un exemple simple pour analyser le processus d'opération de mise à jour.

On crée d'abord une table avec un ID de clé primaire et un champ entier c :

mysql> create table demo T (ID int primarty ,c int);复制代码

Copier après la connexion

Puis on ajoute 1 à la valeur de la ligne avec ID=2

mysql> update table demo set c = c + 1 where ID = 2;复制代码

Copier après la connexion

Suivant , jetons un coup d'œil au processus d'exécution de l'instruction update. La case lumineuse dans la figure représente l'exécution dans le moteur de stockage et la case colorée représente l'exécution dans l'exécuteur.

On voit qu'à la fin, l'écriture du redolog se divise en deux étapes, préparer et commettre. C'est ce qu'on appelle souvent le « commit en deux phases ».

Pourquoi le journal doit-il être « soumis en deux phases » ?

Puisque redo log et binlog sont respectivement les journaux du moteur de stockage et de l'exécuteur, ce sont deux logiques indépendantes si la soumission en deux étapes n'est pas utilisée, il y aura des problèmes quelle que soit celle qui est soumise en premier. et lequel est soumis plus tard. Jetons un coup d'œil à l'exemple ci-dessus. Supposons que la valeur actuelle de la ligne avec ID=2 soit 0. Une fois le premier journal écrit pendant le processus de mise à jour, un crash se produit alors que le deuxième journal n'est pas écrit. ?

Écrivez d'abord redolog puis binlog. Supposons que le redolog a été écrit mais que le binlog n'a pas encore été écrit et que le processus MySQL redémarre anormalement. Nous savons qu'une fois le redolog écrit, les données peuvent être restaurées même si le système tombe en panne, donc après le redémarrage de MySQL, cette ligne sera restaurée à 1. Étant donné que le journal binaire se bloque avant d'être terminé, il n'existe pas d'instruction de ce type dans le journal binaire pour le moment. Par conséquent, lorsque le journal est sauvegardé ultérieurement, le journal binlog enregistré ne contient pas cette instruction. Lorsque nous devons restaurer des données via binlog, parce que binlog a perdu cette instruction, la valeur de la ligne restaurée est 0, ce qui est différent de la valeur de la base de données d'origine.
Écrivez d'abord le binlog, puis refaites le journal. Si après l'écriture du buglog, un crash se produit avant que le redo log ne soit terminé, et si la base de données plante à ce moment-là, la transaction sera invalide après la récupération, donc la valeur de cette ligne est toujours 0, mais l'instruction de mise à jour a été enregistrée. dans le journal binlog, lorsque vous devrez utiliser binlog pour restaurer des données à l'avenir, il y aura une transaction supplémentaire pour mettre à jour la valeur de 0 à 1, ce qui est différent du 0 dans la base de données d'origine.

Nous pouvons voir que si la « validation en deux phases » n'est pas utilisée, l'état de la base de données sera incohérent avec la base de données restaurée à l'aide des journaux. Bien que la probabilité d'utiliser des journaux pour récupérer des données soit relativement faible, l'utilisation la plus courante des journaux se fait lors de l'expansion de la capacité, qui est obtenue via une sauvegarde complète et un binlog. Cela peut entraîner des incohérences entre les bases de données maître-esclave en ligne.