Comment les instructions SQL sont-elles exécutées dans MySQL ?

Ce que cet article vous apporte, c'est comment exécuter des instructions SQL dans MySQL ? Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Cet article analysera le processus d'exécution de la prochaine instruction SQL dans MySQL, y compris la façon dont la requête SQL circule dans MySQL et comment la mise à jour de l'instruction SQL est terminée.

Avant d'analyser, je vais vous amener à examiner l'infrastructure de MySQL. Savoir de quels composants MySQL se compose et quelles sont les fonctions de ces composants peut nous aider à comprendre et à résoudre ces problèmes.

Une analyse de l'infrastructure MySQL

1.1 Présentation de l'architecture de base de MySQL

La figure suivante est un bref diagramme d'architecture de MySQL À partir de la figure ci-dessous, vous. peut facilement voir clairement comment l'instruction SQL de l'utilisateur est exécutée dans MySQL.

Présentons brièvement les fonctions de base de certains composants impliqués dans l'image ci-dessous pour aider tout le monde à comprendre cette image. Les fonctions de ces composants seront présentées en détail dans la section 1.2.

Connecteur : L'authentification de l'identité est liée aux autorisations (lors de la connexion à MySQL).

Cache de requête : Lors de l'exécution d'une instruction de requête, le cache sera interrogé en premier (supprimé après MySQL version 8.0, car cette fonction n'est pas très pratique).

Analyseur : Si le cache n'est pas atteint, l'instruction SQL passera par l'analyseur Pour parler franchement, l'analyseur doit d'abord voir ce que fait votre instruction SQL, puis. vérifiez votre instruction SQL. La syntaxe est-elle correcte ?

Optimiseur : Exécuter selon ce que MySQL considère comme la solution optimale.

Exécuteur : Exécute l'instruction et renvoie les données du moteur de stockage.

De manière simple, MySQL est principalement divisé en couche serveur et couche moteur de stockage :

Couche serveur : comprend principalement les connecteurs et les requêtes Cache, analyseur, optimiseur, exécuteur, etc., toutes les fonctions du moteur de stockage croisé sont implémentées dans cette couche, telles que les procédures stockées, les déclencheurs, les vues, les fonctions, etc., et il existe également un module de journalisation général binglog log module.

Moteur de stockage : principalement responsable du stockage et de la lecture des données. Il adopte une architecture de plug-in remplaçable et prend en charge plusieurs moteurs de stockage tels que InnoDB, MyISAM et Memory. Parmi eux, InnoDB. Le moteur a son propre module redolog du module de journalisation. Le moteur de stockage le plus couramment utilisé est désormais InnoDB, qui est utilisé comme moteur de stockage par défaut depuis la version 5.5.5 de MySQL.

1.2 Introduction aux composants de base de la couche Serveur

1) Connecteur

Les connecteurs sont principalement liés aux fonctions liées à l'authentification de l'identité et aux autorisations, tout comme un très haut niveau Comme le portier.

est principalement responsable de la connexion de l'utilisateur à la base de données et de l'authentification de l'identité de l'utilisateur, y compris la vérification des mots de passe des comptes, des autorisations et d'autres opérations. Si le mot de passe du compte utilisateur a été transmis, le connecteur interrogera toutes les autorisations de l'utilisateur dans le fichier. table des autorisations, puis Le jugement logique des autorisations dans cette connexion s'appuiera sur les données d'autorisation lues à ce moment-là. En d'autres termes, tant que la connexion n'est pas déconnectée, même si l'administrateur modifie les autorisations de l'utilisateur, l'utilisateur ne le sera pas. affecté.

2) Cache de requêtes (supprimé après la version MySQL 8.0)

Le cache de requêtes est principalement utilisé pour mettre en cache l'instruction SELECT que nous exécutons et l'ensemble de résultats de l'instruction.

Une fois la connexion établie, lors de l'exécution de l'instruction de requête, le cache sera d'abord interrogé. MySQL vérifiera d'abord si le SQL a été exécuté et le mettra en cache dans la mémoire sous la forme d'une clé-valeur. est l'estimation de la requête et la valeur est l'ensemble de résultats. Si la clé de cache est atteinte, elle sera renvoyée directement au client. S'il n'y a pas d'occurrence, les opérations suivantes seront effectuées une fois terminées, le résultat sera mis en cache pour faciliter le prochain appel. Bien entendu, lorsque la requête de cache est réellement exécutée, les autorisations de l'utilisateur seront toujours vérifiées pour voir s'il existe des conditions de requête pour la table.

Il n'est pas recommandé d'utiliser le cache pour les requêtes MySQL, car les échecs du cache de requêtes peuvent être très fréquents dans les scénarios commerciaux réels. Si vous mettez à jour une table, tous les caches de requêtes sur cette table seront effacés. Pour les données qui ne sont pas mises à jour fréquemment, il est toujours possible d'utiliser la mise en cache.

Donc, nous déconseillons généralement d'utiliser le cache de requêtes dans la plupart des cas.

La fonction de cache a été supprimée après la version 8.0 de MySQL. Les responsables pensaient également que cette fonction avait peu de scénarios d'application pratiques, ils l'ont donc simplement supprimée.

3) Analyseur

MySQL n'atteint pas le cache, il entrera alors dans l'analyseur. L'analyseur est principalement utilisé pour analyser à quoi sert l'instruction SQL. L'analyseur sera également divisé en. plusieurs catégories. Étape :

La première étape est l'analyse lexicale . Une instruction SQL est composée de plusieurs chaînes. Vous devez d'abord extraire des mots-clés, tels que sélectionner, proposer la table de requête, proposer un champ. noms, et proposer des conditions de requête, etc. Après avoir terminé ces opérations, vous entrerez dans la deuxième étape.

La deuxième étape, l'analyse syntaxique, consiste principalement à déterminer si le SQL que vous avez saisi est correct et conforme à la syntaxe de MySQL.

Après avoir terminé ces 2 étapes, MySQL est prêt à démarrer l'exécution, mais comment l'exécuter et comment obtenir le meilleur résultat ? À ce stade, l’optimiseur doit entrer en jeu.

4) Optimiseur

La fonction de l'optimiseur est d'exécuter ce qu'il considère comme le plan d'exécution optimal (parfois il peut ne pas être optimal. Cet article implique une explication approfondie de ces connaissances), Par exemple, comment choisir un index lorsqu'il existe plusieurs index, comment choisir l'ordre d'association lors de l'interrogation de plusieurs tables, etc.

On peut dire qu'après avoir passé par l'optimiseur, on peut dire que l'exécution spécifique de cette instruction a été déterminée.

5) Exécuteur

Après avoir sélectionné le plan d'exécution, MySQL est prêt à démarrer l'exécution. Tout d'abord, il vérifiera si l'utilisateur a l'autorisation avant l'exécution. S'il n'y a pas d'autorisation, une erreur se produira. être renvoyé.Informations, s'il en a l'autorisation, il appellera l'interface du moteur et renverra le résultat de l'exécution de l'interface.

2 Analyse des instructions

2.1 Instruction de requête

Cela dit, comment une instruction SQL est-elle exécutée ? En fait, notre SQL peut être divisé en deux types, l'un est une requête et l'autre est une mise à jour (ajouter, mettre à jour, supprimer). Analysons d'abord l'instruction de requête. L'instruction est la suivante :

select * from tb_student  A where A.age='18' and A.name=' 张三 ';

En combinaison avec la description ci-dessus, nous analysons le flux d'exécution de cette instruction :

Vérifiez d'abord si l'instruction a l'autorisation. . S'il n'y a pas d'autorisation, renvoie directement les informations d'erreur. Si vous avez l'autorisation, avant la version MySQL8.0, le cache sera d'abord interrogé et cette instruction SQL sera utilisée comme clé pour demander s'il y a un résultat dans le fichier. mémoire. S'il existe un cache direct, sinon, passez à l'étape suivante.

Effectuez une analyse lexicale via l'analyseur et extrayez les éléments clés de l'instruction SQL. Par exemple, l'instruction ci-dessus est une sélection de requête. Le nom de la table à interroger est tb_student. interrogé. Les conditions de requête sont L'identifiant de cette table est '1'. Déterminez ensuite si l'instruction SQL contient des erreurs de syntaxe, par exemple si les mots clés sont corrects, etc. S'il n'y a pas de problème, passez à l'étape suivante.

L'étape suivante consiste pour l'optimiseur à déterminer le plan d'exécution. L'instruction SQL ci-dessus peut avoir deux plans d'exécution :

  a.先查询学生表中姓名为“张三”的学生，然后判断是否年龄是 18。
  b.先找出学生中年龄 18 岁的学生，然后再查询姓名为“张三”的学生。

Ensuite, l'optimiseur choisit en fonction de sa propre optimisation. algorithme La solution avec la meilleure efficacité d'exécution (l'optimiseur estime que parfois ce n'est peut-être pas la meilleure). Ensuite, après avoir confirmé le plan d'exécution, vous êtes prêt à démarrer l'exécution.

Effectuez la vérification des autorisations. S'il n'y a pas d'autorisation, un message d'erreur sera renvoyé. S'il y a une autorisation, l'interface du moteur de base de données sera appelée et le résultat de l'exécution du moteur sera renvoyé.

2.2 Instruction de mise à jour

Ce qui précède est le processus d'exécution d'une requête SQL, voyons donc comment une instruction de mise à jour est exécutée ? L'instruction sql est la suivante :

update tb_student A set A.age='19' where A.name=' 张三 ';

Modifions l'âge de Zhang San. Le champ d'âge ne sera certainement pas défini dans la base de données réelle, sinon il sera battu par le responsable technique. En fait, chaque instruction suivra essentiellement le processus de la requête précédente, mais le journal doit être enregistré lors de l'exécution de la mise à jour. Cela introduira le propre module de journalisation de MySQL binlog (archive log), tous les moteurs de stockage peuvent être utilisés, notre moteur InnoDB couramment utilisé est également livré avec un module de journalisation redo log (redo log) , nous discuterons de l'exécution de cette instruction dans le processus en mode InnoDB. Le processus est le suivant :

Interrogez d'abord les données de Zhang San S'il existe un cache, le cache sera également utilisé.

Ensuite, récupérez l'instruction de requête, modifiez l'âge à 19, puis appelez l'interface API du moteur pour écrire cette ligne de données. Le moteur InnoDB enregistre les données dans la mémoire et enregistre le journal de rétablissement en même temps. À ce moment-là, le journal redo entre dans l'état de préparation. Indiquez ensuite à l'exécuteur que l'exécution est terminée et peut être soumise à tout moment.

Après avoir reçu la notification, l'exécuteur enregistre le binlog, puis appelle l'interface du moteur et soumet le journal redo comme statut de soumission.

Mise à jour terminée.

Certains étudiants ici se demanderont certainement pourquoi devons-nous utiliser deux modules de journalisation au lieu d'un module de journalisation ?

C'est parce que MySQL ne fonctionnait pas avec InnoDB à le début. Engine (le moteur InnoDB est inséré dans MySQL sous la forme d'un plug-in par d'autres sociétés). Le moteur de MySQL est MyISAM, mais nous savons que le journal redo est unique au moteur InnoDB et n'est pas disponible dans d'autres moteurs de stockage. . Cela entraîne un manque de fonctionnalités de sécurité contre les crashs (avec la fonctionnalité de sécurité contre les crashs, même si la base de données redémarre anormalement, les enregistrements précédemment soumis ne seront pas perdus uniquement pour l'archivage).

Cela ne signifie pas que vous ne pouvez pas utiliser un seul module de journalisation, mais le moteur InnoDB prend en charge les transactions via redo log. Ensuite, certains étudiants demanderont : puis-je utiliser deux modules de journalisation, mais ce n'est pas si compliqué ? Pourquoi le redo log introduit-il la préparation de l'état de pré-validation ? Ici, nous utilisons la preuve par contradiction pour expliquer pourquoi nous faisons cela ?

Écrivez d'abord le journal de rétablissement et soumettez-le directement, puis écrivez le journal binaireSupposons qu'après avoir écrit le journal de rétablissement, la machine se bloque et le journal du journal binaire ne soit pas écrit. la machine est redémarrée, la machine Les données sont restaurées via le journal redo, mais bingog n'enregistre pas les données pour le moment. Lorsque la machine est sauvegardée ultérieurement, cette donnée sera perdue et la synchronisation maître-esclave sera également perdue. perdre cette donnée.

Écrivez d'abord le journal binaire, puis écrivez le journal redo Supposons qu'après avoir écrit le journal binaire, la machine redémarre anormalement puisqu'il n'y a pas de journal redo, la machine ne peut pas restaurer cet enregistrement, mais le binlog a Record, alors la même raison que ci-dessus entraînera une incohérence des données.

Si la méthode de soumission du redo log en deux étapes est utilisée, ce sera différent. Après avoir écrit le binglog, puis soumettre le redo log évitera les problèmes ci-dessus et garantira la cohérence des données. La question est donc : existe-t-il une situation extrême ? Supposons que le journal de rétablissement soit dans l'état de pré-validation et que le journal binglog ait été écrit. Que se passera-t-il si un redémarrage anormal se produit à ce moment-là ?
Cela dépend du mécanisme de traitement de MySQL. Le processus de traitement de MySQL est le suivant :

Déterminez si le journal redo est complet. S'il est jugé complet, soumettez-le immédiatement.

Si le journal redo est uniquement pré-soumis mais pas en statut de validation, alors il sera jugé si le binlog est complet, s'il est complet, le journal redo sera soumis. S'il est incomplet, la transaction sera. reculé.

Cela résout le problème de cohérence des données.

Trois résumés

MySQL est principalement divisé en couches serveur et moteur. La couche serveur comprend principalement des connecteurs, des caches de requêtes, des analyseurs, des optimiseurs et des exécuteurs. un module de journalisation (binlog), qui peut être partagé par tous les moteurs d'exécution Redolog n'est disponible que dans InnoDB.

La couche moteur est plug-in et comprend actuellement principalement MyISAM, InnoDB, Memory, etc.

Le processus d'exécution de l'instruction de requête est le suivant : Vérification des autorisations (si le cache est atteint)---"Cache de requête---"Analyzer---"Optimiseur---"Vérification des autorisations---"Exécuteur - --》Moteur

Le processus d'exécution de l'instruction de mise à jour est le suivant : Analyseur----》Vérification des autorisations----》Exécuteur---》Moteur---redo log (préparer le statut--- 》 binlog ---》redo log (statut de validation) [Recommandations associées : Tutoriel 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!