Explication détaillée de l'état du thread MySQL

Répertoire des articles

• • 1. show processlist
  • 2.
  • 3. Statut du thread utilisateur
  • 4. Statut du thread de vidage
  • 5. Statut du thread IO
  • 6. 7. État du fil de connexion maître-esclave
  • 8. État du fil de planification d'événements

Recommandations d'apprentissage gratuites associées :

Tutoriel vidéo MySQL

1. Afficher la liste des processus

Id : identifiant du processus de connexion. Est la valeur renvoyée par la fonction CONNECTION_ID()

• Utilisateur : Le nom de l'utilisateur MySQL qui a exécuté l'instruction. Si « utilisateur système » est affiché, il fait référence au thread non client généré par MySQL qui effectue des tâches internes. Par exemple, les threads d'E/S ou SQL utilisés sur les bibliothèques
esclaves dans la réplication principale-de secours ou les threads pour les gestionnaires de lignes retardés. « utilisateur non authentifié » fait référence au thread dans lequel le client a établi une connexion TCP/IP avec le serveur mais n'a pas encore authentifié le mot de passe utilisateur du client. « event_scheduler » fait référence au thread qui surveille les événements de planification de tâches planifiés.
• 
  Host : Le nom d'hôte du client exécutant l'instruction, affiché dans host_name:client_port (si le paramètre skip_name_resolve est activé, il est affiché au format ip:client_port)
• Db : La valeur par défaut base de données à laquelle le client se connecte (Si le nom de la bibliothèque est précisé lors de la connexion), sinon il s'affiche comme NULL.
• Command : Le type de commande exécutée par le thread.
• Durée : la durée (en secondes) pendant laquelle le fil est resté dans l'état actuel. Pour les threads SQL esclaves, cette valeur correspond au nombre de secondes entre l'heure du dernier événement de réplication et l'heure réelle de l'esclave.
• État : indique le type d'opération, d'événement ou d'état effectué par le thread.
• Info : L'instruction en cours d'exécution par le thread.

2. Type de commande

Binlog Dump : Le thread de la bibliothèque principale est utilisé pour envoyer le contenu du journal binaire à la bibliothèque esclave

• Changer d'utilisateur : le thread effectue une opération de changement d'utilisateur
• Fermer stmt : le thread ferme une instruction précompilée
• Connecter : le thread esclave a été connecté à la bibliothèque principale
• Connect Out : La bibliothèque esclave se connecte à la bibliothèque principale
• Créer une base de données : Le thread effectue une opération de création de base de données
• Démon : Il s'agit d'un thread interne du serveur, pas un thread pour la connexion client
• Debug : le thread génère des informations de débogage
• Insertion retardée : c'est un thread qui retarde le gestionnaire d'insertion
• Drop DB : le thread est en cours d'exécution une opération de suppression de base de données
• Execute : Thread Exécution d'une instruction précompilée
• Fetch : Le thread exécute l'instruction et en obtient l'ensemble de résultats
• Liste de champs : Le thread est récupérer les informations sur les colonnes de la table
• Init DB : le thread sélectionne la base de données par défaut
• Kill : le thread tue les autres threads
• Données longues : le thread exécute l'instruction et récupère et renvoie un champ long (grand champ) tapez le résultat des données à partir de celui-ci
• Ping : le thread traite la demande de ping du serveur
• Préparer : le thread est en cours d'exécution pour précompiler une instruction
• Processlist : Le thread génère des informations sur le thread du serveur
• Requête : Le thread exécute l'instruction de requête
• Quitter : Le thread se termine
• Actualiser : Le thread actualise la table , journaliser ou mettre en cache, ou réinitialiser les variables d'état ou copier les informations du serveur
• Register Slave : Le thread enregistre la bibliothèque esclave sur la bibliothèque principale
• Reset stmt : Le thread réinitialise l'instruction précompilée
• Définir l'option : le thread définit ou réinitialise l'option d'exécution de l'instruction client
• Arrêt : le thread arrête le serveur
• Veille : le thread attend que le client envoyez-lui une nouvelle demande de déclaration
• Statistiques : le thread génère des informations sur l'état du serveur
• Dump de table : le thread envoie le contenu de la table à la bibliothèque esclave

3. Statut du fil de discussion

• Après la création : cet état se produit lorsque le thread termine la création d'une table (y compris les tables temporaires internes).
  Ce statut se produit même si la création de la table aboutit à une erreur due à une erreur
• Analyse : le thread est ANALYZE TABLE
• vérification des autorisations : vérification sur le serveur si le thread a une instruction d'exécution requise autorisations
• Vérification de la table : le thread effectue une opération de vérification de la table
• nettoyage : le thread a terminé l'exécution d'une commande et se prépare à libérer la mémoire occupée et à réinitialiser certaines variables d'état
• fermeture des tables : le thread vide les données modifiées de la table sur le disque et ferme la table.
• conversion de HEAP en MyISAM : le thread convertit la table temporaire interne de la table du moteur MEMORY en table temporaire sur le disque du moteur MyISAM
• copie vers la table tmp : le thread exécute l'instruction ALTER TABLE. Cet état se produit après la création de la table avec la nouvelle structure et avant de copier les anciennes données de la table dans la nouvelle table
• Copie vers la table de groupe : si l'instruction utilise des colonnes conditionnelles ORDER BY et GROUP BY différentes, alors Trier ces lignes de données selon le groupe par, et copiez les résultats triés dans la table temporaire
• Copie vers la table tmp : le serveur copie les données dans la table temporaire de la mémoire
• modification de la table : le serveur est en cours d'exécution Processus ALTER TABLE in -Place
• Copie vers la table tmp sur le disque : le serveur copie les données sur la table temporaire du disque. Parce que le jeu de résultats temporaires est trop volumineux, le thread convertit la table temporaire en mémoire en table temporaire sur disque pour économiser de la mémoire.
• Création d'un index : le thread exécute un ALTER TABLE ... ENABLE KEYS instruction
• Création d'un index de tri : Le thread exécute SELECT et la table temporaire interne est utilisée
• Création d'une table : Le thread est en train de créer la table. Ce statut est également utilisé lors de la création de tables temporaires
• Création d'une table tmp : Le thread crée une table temporaire en mémoire ou sur disque. Si la table a été créée en mémoire mais convertie ultérieurement en table de disque, l'état pendant l'opération sera "Copie vers la table tmp sur le disque"
• validation de la table alter dans le moteur de stockage : le serveur a exécuté son exécution en - Le L'instruction ALTER TABLE de l'algorithme de lieu soumet
• suppression de la table principale : le serveur exécute la première partie de l'instruction de suppression multi-table. Voir cet
  statut indique qu'il est en cours de suppression de la première table, et les données de colonne et les décalages utilisés pour supprimer les tables suivantes sont enregistrés
• suppression des tables de référence : Le serveur exécute une suppression multi-tables instruction La deuxième partie, supprimez les lignes correspondantes des autres tables
• discard_or_import_tablespace : le thread est en cours d'exécution ALTER TABLE … DISCARD TABLESPACE ou ALTER TABLE … Instruction IMPORT TABLESPACE
• end : cela se produit à la fin de l'exécution de l'instruction Cet état se produit lorsque, mais avant d'effacer l'instruction ALTER TABLE, CREATE VIEW, DELETE, INSERT, SELECT ou UPDATE
• en cours d'exécution : le thread exécute l'instruction
• Exécution de init_command : le thread est en cours d'exécution. exécuter une instruction pour initialiser les variables système
• libérer les éléments : le thread a terminé l'exécution d'une commande. Libérez certains éléments liés à l'état du cache des requêtes
  . Cet état est généralement suivi de l'état de nettoyage
• Initialisation FULLTEXT : Le serveur se prépare à effectuer une recherche en texte intégral en langage naturel
• init : Ceci est initialisé dans ALTER TABLE, DELETE, INSERT , SELECT ou UPDATE état d'instruction qui s'est produit auparavant. Les opérations effectuées par le serveur dans cet état incluent l'actualisation du journal binaire, du journal InnoDB et certaines opérations de nettoyage du cache de requêtes. A la fin de cet état, les opérations suivantes peuvent être effectuées :
  Supprimer les entrées du cache des requêtes lorsque les données de la table changent
  Écrire les événements dans le journal binaire
  Libérez les tampons de mémoire, y compris blob
• Killed : lancez une opération de destruction sur le thread, et le thread doit effectuer l'opération de terminaison. L'indicateur de suppression d'un thread est vérifié dans chaque boucle principale de MySQL, mais dans certains cas, la suppression du thread peut ne prendre que peu de temps. Cependant, si le thread en cours de suppression est verrouillé par d'autres threads, vous devez attendre que d'autres threads libèrent le verrou avant que la commande kill ne prenne effet et ne soit exécutée.
• logging des requêtes lentes : le thread écrit une instruction dans le journal des requêtes lentes.
• login : l'état initial du thread de connexion jusqu'à ce que le client s'authentifie avec succès
• gérer les clés : serveur Activation ou désactivation des index de table
• NULL : Ce statut est utilisé pour l'instruction SHOW PROCESSLIST
• Ouverture de tables : Le thread tente d'ouvrir une table. Les opérations d'ouverture de table doivent être très rapides à moins que l'opération d'ouverture ne soit bloquée. Par exemple, une instruction ALTER TABLE ou LOCK TABLE empêche l'ouverture de la table jusqu'à la fin de l'instruction. De plus, il se peut que table_open_cache ne soit pas assez grand et que la table ne puisse pas être ouverte.
• optimisation : le serveur effectue une optimisation initiale sur la requête
• préparation : cet état se produit lors de l'optimisation de la requête
• Purger les anciens journaux de relais : le thread supprime les journaux de relais inutiles Fichier
• Fin de la requête : cet état apparaît après l'exécution de l'instruction de requête mais avant de libérer les éléments d'état liés à l'instruction de requête.
• Lecture à partir du réseau : Le serveur lit les paquets de données du réseau. Après MySQL 5.7.8, cet état est appelé « Réception du client » - Réception du client : Le serveur lit les paquets du client. Dans MySQL 5.7.8, cela s'appelle "Lecture à partir du réseau"
• Suppression des doublons : lorsque la requête utilise l'instruction SELECT DISTINCT, MySQL ne peut pas optimiser l'opération distincte au début. Par conséquent, MySQL nécessite une étape supplémentaire pour supprimer toutes les lignes en double, puis envoyer les résultats au client
• suppression de la table tmp : le thread supprime la table temporaire interne une fois l'exécution de l'instruction SELECT terminée. Si l'instruction SELECT ne crée pas de table temporaire, cet état ne se produira pas
• rename : le thread exécute l'instruction rename pour renommer la table
• rename result table : le thread exécute l'instruction rename pour renommer la table. Instruction ALTER TABLE pour renommer la table, Une nouvelle table a été créée et l'ancien nom de la table est remplacé par la nouvelle table
• Réouvrir les tables : Le thread a obtenu le verrou de la table, mais après avoir obtenu le verrou, il a trouvé que la structure de la table sous-jacente a été modifiée.
  Alors libérez le verrou de la table, fermez la table et essayez de rouvrir la table
• Réparez par tri : Le code de réparation utilise le tri pour créer l'index
• prépare la modification de la table : le serveur se prépare à s'exécuter dans - Instruction ALTER TABLE de l'algorithme -place - Réparation effectuée : Ce thread a terminé la réparation multithread de la table MyISAM
• Réparation avec keycache : Le code de réparation répare l'index à l'aide du méthode de création de clés une par une via le cache de clés. C'est beaucoup plus lent que la méthode de réparation par index trié
• Rolling back : le thread annule la transaction
• Enregistrement de l'état : pour les opérations sur la table MyISAM (telles que la réparation ou l'analyse), le le thread annule la nouvelle table. Le statut est enregistré dans l'en-tête du fichier .MYI. L'état comprend : des informations telles que le nombre de lignes de données de la table, le compteur AUTO_INCREMENT et la distribution des clés
  
Recherche de lignes à mettre à jour : le thread effectue la première phase pour trouver toutes les lignes correspondantes avant de les mettre à jour. Si UPDATE modifie l'index utilisé pour trouver les lignes impliquées, les lignes qui correspondent à la mise à jour doivent être trouvées en premier
• Envoi de données : le thread lit et traite les lignes de données générées par l'instruction SELECT, et envoie le données au client. Étant donné que les opérations se produisant pendant cet état peuvent générer un accès disque important (lectures), il s'agit généralement de l'état d'exécution le plus long au cours de la durée de vie d'une requête donnée.
• Envoi au client : le serveur envoie au client un paquet d'écriture. Avant MySQL 5.7.8, cela s'appelait « Écriture sur le réseau »
• configuration : le thread effectue une opération ALTER TABLE
• Tri pour le groupe : le thread effectue une opération de tri GROUP BY
• Tri par ordre : le fil effectue une opération de tri ORDER BY
• Tri de l'index : le fil trie les pages d'index pour obtenir un accès plus efficace lors de l'opération d'optimisation de la table MyISAM
• Résultat du tri : pour l'instruction SELECT, ceci est similaire à l'état "Création d'un index de tri", mais pour les tables non temporaires
• statistiques : le serveur calcule des statistiques pour optimiser le plan d'exécution de la requête. Si un thread reste dans cet état pendant une longue période, le serveur peut effectuer d'autres tâches sur le disque et bloquer le fonctionnement des informations statistiques, ou une attente de verrouillage peut se produire.
• Verrouillage système : le thread appelé mysql_lock_tables() et l'état du thread n'ont jamais été mis à jour. Il s’agit d’un état très courant et peut survenir pour de nombreuses raisons. Par exemple, un thread demandera ou attendra un verrou système interne ou externe sur une table. Cela peut se produire lorsqu'InnoDB attend des verrous au niveau de la table pendant LOCK TABLES. Si cet état est provoqué par une demande de verrouillage externe, vous pouvez utiliser l'option –skip-external-locking pour désactiver le verrouillage externe du système si vous n'utilisez pas plusieurs serveurs mysqld pour accéder à la même table MyISAM. Cependant, le verrouillage externe est désactivé par défaut, cette option peut donc n'avoir aucun effet.
• Pour SHOW PROFILE, cet état indique que le thread demande un verrouillage
• mise à jour : le thread est prêt à commencer la mise à jour de la table
• Mise à jour : le thread recherche et met à jour les lignes de données
• mise à jour de la table principale : serveur La première partie de l'instruction de mise à jour multi-table est en cours d'exécution. Cet état indique que
  met à jour la première table et enregistre les valeurs et les décalages des colonnes pour les utiliser dans la mise à jour d'autres tables (de référence).
• met à jour les tables de référence : Le serveur exécute la deuxième d'une multi-table section d'instruction de mise à jour, met à jour les lignes correspondantes d'autres tables
  
• Verrouillage utilisateur : le thread demandera ou attend le verrou proposé demandé via un appel GET_LOCK(). Pour SHOW PROFILE, cet état indique que le thread demande le verrouillage (sans attendre)
• Veille de l'utilisateur : Le thread a appelé SLEEP() Appelé
• En attente du verrouillage de validation : FLUSH TABLES WITH READ L'instruction LOCK obtient le verrou de soumission
• En attente du verrou de lecture global : FLUSH TABLES AVEC READ LOCK En attente d'acquisition du verrou de lecture global ou du paramètre de variable système global en lecture seule
• En attente des tables : le fil de discussion reçoit une notification , la couche inférieure de la table. La structure a changé et il faut rouvrir la table pour obtenir la nouvelle structure. Cependant, pour rouvrir la table, il faut attendre que tous les autres threads aient fermé l'accès à la table pour l'ancienne structure de données. Cette notification se produit si un autre thread a utilisé FLUSH TABLES ou l'une des instructions suivantes sur la table :
  

FLUSH TABLES tbl_name
• ALTER TABLE
RENAME TABLE * REPAIR TABLE
• ANALYZE TABLE
• OPTIMIZE TABLE

En attente du vidage de la table : Le thread exécute FLUSH TABLES et attend Tous les threads ferment le table accédée, ou un thread est informé que la structure sous-jacente d'une table a changé et qu'il doit rouvrir la table pour obtenir la nouvelle structure. Cependant, pour rouvrir la table, il faut attendre que tous les autres threads aient fermé l'accès à l'ancienne structure de la table. Cette notification se produit si un autre thread a utilisé FLUSH TABLES ou l'une des instructions suivantes sur la table :

FLUSH TABLES tbl_name
• ALTER TABLE
RENAME TABLE
• REPAIR TABLE
• ANALYZE TABLE
• OPTIMIZE TABLE

En attente du verrou lock_type : le serveur attend d'obtenir un verrou THR_LOCK ou un verrou MDL obtenu à partir du sous-système de verrouillage des métadonnées, où lock_type indique le type de verrou MDL qui attend d'être obtenu. Il n'existe qu'un seul type de verrou THR_LOCK (en attente de verrouillage au niveau de la table). 🎜>

En attente du verrouillage des métadonnées d'événement

• En attente du verrouillage global en lecture
• En attente du verrouillage des métadonnées du schéma
• En attente du verrouillage des métadonnées de la fonction stockée
• En attente du verrouillage des métadonnées de la procédure stockée
• En attente du verrouillage des métadonnées de la table
• En attente du verrouillage des métadonnées du déclencheur

En attente de cond : Le fil de discussion est en cours. Un état général qui attend qu'une condition devienne vraie. Aucune information d'état spécifique disponible

• Écriture sur le réseau : le serveur écrit des paquets sur le réseau. À partir de MySQL 5.7.8, cela s'appelle "Envoi au client"

4. Vider l'état du thread

J'ai fini de lire un journal binaire en passant à ; prochain binlog : le thread a fini de lire le fichier binlog

et est passé au fichier binlog suivant
• 
  Le maître a envoyé tous les binlogs à l'esclave en attendant plus de mises à jour : le thread a lu tous les fichiers binlog restants du ; Le journal binaire met à jour les journaux et les envoie à la bibliothèque esclave. Le thread est actuellement inactif et attend que de nouveaux événements de données mis à jour soient écrits dans le journal binaire
• Envoi de l'événement binlog à l'esclave : le thread a lu un événement dans le journal binaire et l'envoie maintenant à la bibliothèque esclave. (Le journal binaire est composé d'événements, et un événement est généralement composé de données mises à jour et d'autres informations)
• En attente de finalisation de la terminaison : un état de très courte durée qui se produit lorsque le thread s'arrête et que le thread est en cours d'exécution pour arrêter l'action liée au thread

5. Statut du thread IO

.

• Vérification de la version maître : Un état très court après l'établissement d'une connexion avec la bibliothèque maître, indiquant que le numéro de version de la bibliothèque maître est en cours de vérification.
• Connexion au maître : Le thread tente de se connecter à la bibliothèque principale
• Mise en file d'attente de l'événement principal dans le journal de relais : le thread a lu un événement et l'a copié dans le journal de relais pour le relire par le thread SQL
• Reconnexion après un échec de demande de vidage du journal binaire : Le fil tente de se reconnecter à la bibliothèque maître
• Reconnexion après un échec de lecture d'un événement maître : Le fil tente de se reconnecter à la bibliothèque maître. Lorsque la reconnexion réussit, l'état passe à "En attente du maître. pour envoyer l'événement" - Enregistrement de l'esclave sur le maître : Un état très court après une connexion réussie à la bibliothèque principale, indiquant que les informations de connexion de la bibliothèque esclave sont en cours d'enregistrement auprès de la bibliothèque maître (telles que les informations IP et de port de la bibliothèque esclave , etc.)
• Demande de vidage du journal binaire : après la connexion à la bibliothèque principale Dans un état très court après que la bibliothèque ait établi avec succès une connexion, elle utilise la
  position actuelle du thread d'E/S pour envoyer une requête à la bibliothèque principale pour le contenu du log binaire à partir de la position actuelle
• En attente de son tour de commit : Si le paramètre slave_preserve_commit_order est activé,
  indique que le thread d'E/S de la bibliothèque esclave est en attente pour qu'un thread de travail plus ancien soumette des données
• En attente de l'envoi de l'événement par le maître : le thread s'est connecté à la bibliothèque principale et attend un nouveau événement de journalisation binaire
  , cela peut durer longtemps si la bibliothèque principale est inactive. Si l'attente dure plus de slave_net_timeout secondes, le thread d'E/S esclave expire. A ce moment, le thread d'E/S de la bibliothèque esclave pense que la connexion à la bibliothèque maître est déconnectée, et va tenter de se reconnecter à la bibliothèque maître
• En attente de mise à jour du maître : l'état initial avant de se connecter au maître bibliothèque
• En attente du mutex esclave à la sortie : un état qui se produit brièvement lorsque le thread s'arrête, indiquant que les ressources mutuellement exclusives pertinentes du thread d'E/S sont en cours de recyclage
• En attente de l'esclave Thread SQL pour libérer suffisamment d'espace de journal de relais : si la valeur de paramètre de la variable relay_log_space_limit n'est pas 0, alors lorsque la taille totale du journal de relais dépasse cette valeur. Le thread d'E/S attendra que le thread SQL libère l'espace occupé par le journal de relais en rejouant le contenu du journal de relais et en supprimant le journal de relais relu, de sorte que la taille du journal de relais ne soit pas supérieure à la valeur de la variable relay_log_space_limit. , le thread d'E/S peut continuer à écrire des opérations de journal de relais.
• En attente de reconnexion après l'échec d'une demande de vidage du journal binaire : si la demande de vidage du journal binaire échoue (en raison d'une déconnexion), alors le thread entre en état de veille. Cet état se produit à ce moment-là, puis les E/S. le thread essaie périodiquement de se reconnecter à la bibliothèque principale. L'intervalle entre les tentatives peut être spécifié à l'aide de l'option MASTER_CONNECT_RETRY de l'instruction CHANGE MASTER TO

• Veuillez noter que le thread d'E/S de la bibliothèque esclave a un mécanisme de battement de cœur lors de la connexion au principal. Lorsqu'aucun nouvel événement n'est envoyé à l'esclave après ce temps de pulsation, le thread d'E/S lance une requête de pulsation à la bibliothèque principale. Si la demande réussit, le temps de pulsation est réinitialisé lorsque la bibliothèque principale envoie un nouvel événement. à l'esclave, ce temps de battement de coeur Une réinitialisation se produira également. Temps de pulsation Défini par l'option MASTER_HEARTBEAT_PERIOD de l'instruction change master (en secondes), plage de 0 à 4294967 secondes, résolution (millisecondes) La valeur minimale non nulle est 0,001, représentant 1 milliseconde. Définir l’intervalle sur 0 désactive les battements de cœur. La valeur par défaut est la moitié du paramètre de configuration slave_net_timeout. Ainsi, en théorie, il n'y aura aucune situation dans laquelle le thread d'E/S de la bibliothèque esclave sera déconnecté car la bibliothèque maître n'écrit pas de données lorsque la base de données maître-esclave est normale.

• En attente de reconnexion après un échec de lecture d'un événement maître : une erreur s'est produite lors de la lecture du journal binaire de la bibliothèque principale (en raison d'une déconnexion). Avant que le thread d'E/S ne tente de se reconnecter à la bibliothèque principale, le thread est en veille pendant le nombre de secondes défini par l'option MASTER_CONNECT_RETRY (la valeur par défaut est 60) de l'instruction CHANGE MASTER TO (cette fois correspond à l'intervalle de nouvelle tentative après un échec de reconnexion. )

6. Statut du fil SQL

• Tuer l'esclave : le thread traite l'instruction STOP SLAVE
• Création d'un fichier temporaire (ajouter) avant de rejouer LOAD DATA INFILE : Le thread exécute l'instruction LOAD DATA INFILE et lira les données de la bibliothèque Ajouter au fichier temporaire
• Créer un fichier temporaire (créer) avant de relire LOAD DATA INFILE : Le thread exécute l'instruction LOAD DATA INFILE et crée un fichier temporaire. Le fichier temporaire contient les données de ligne à lire. de la bibliothèque. Remarque : Cet état ne peut être rencontré que dans les versions antérieures à MySQL 5.0.3 lorsque la bibliothèque principale enregistre l'instruction LOAD DATA INFILE d'origine
• Événement de lecture du journal de relais : le thread lit les événements du journal de relais. replay
• L'esclave a lu tous les journaux de relais ; attend plus de mises à jour : le thread a refait tous les événements dans tous les fichiers journaux de relais et attend que le thread d'E/S envoie le journal de relais au journal d'écriture de relais. nouveaux événements dans
• En attente d'un événement du coordinateur : lorsque la bibliothèque esclave utilise la réplication multi-thread (slave_parallel_workers est supérieur à 1), cet état indique qu'un thread de travail esclave attend le thread coordinateur (fil coordinateur ) pour allouer les journaux Événement
• Attente du mutex esclave à la sortie : un état de très courte durée qui se produit lorsque le thread s'arrête
• Attente que les travailleurs esclaves libèrent les événements en attente : lorsque le nombre total de les événements traités par le thread de travail dépasse slave_ending_jobs_size_max Lorsque la taille de la variable système est dépassée, une opération d'attente se produit (le thread coordinateur n'attribue pas d'événements aux threads de travail). Le coordinateur reprend la planification lorsque le nombre total d'événements traités par les threads de travail tombe en dessous de la limite slave_ending_jobs_size_max. Cet état ne se produira que lorsque slave_parallel_workers est défini sur supérieur à 0
• Attente du prochain événement dans le journal de relais : L'état initial avant l'état "Lecture de l'événement dans le journal de relais"
• En attente de MASTER_DELAY secondes après l'exécution de l'événement par le maître : le thread SQL a lu l'événement, mais ne l'a pas appliqué. Au lieu de cela, il attend l'expiration du délai de copie défini par la bibliothèque esclave. Ce délai est défini à l'aide de l'option MASTER_DELAY de CHANGE MASTER TO
  ⚫ La colonne Info du thread SQL peut également afficher le texte de l'instruction. Cela signifie que le thread a lu un événement du journal de relais, en a extrait l'instruction SQL et est peut-être en train d'exécuter l'événement correspondant à cette instruction.

7. État du thread de connexion maître-esclave

• Changement de maître : le thread traite l'instruction CHANGE MASTER TO
• Tuer l'esclave : le thread traite l'instruction STOP SLAVE
• Ouverture de la table de vidage principale : cet état se produit après que la bibliothèque principale a créé la table de vidage
• Lecture des données de la table de vidage principale : l'état qui se produit. après l'état "Ouverture de la table de vidage principale", indiquant que les données sont en cours de lecture à partir de la table de vidage principale de la base de données
• Reconstruction de l'index sur la table de vidage principale : l'état qui apparaît après "Lecture des données de la table de vidage principale" L'état indique que l'index de la table de vidage de la base de données principale est en cours de reconstruction

8. Statut du fil de planification d'événements

• Effacement : le thread du planificateur s'arrête. exécuter les événements
• Initialisé : le thread du planificateur a été initialisé. L'événement de planification est sur le point d'être exécuté
• En attente de la prochaine activation : lorsque le planificateur a une file d'attente d'événements non vide, il attend. un événement dans la file d'attente d'activation à activer à un moment donné dans le futur afin de planifier et d'exécuter
• Attente de l'arrêt du planificateur : Le thread émet SET GLOBAL event_scheduler = OFF et attend que le planificateur s'arrête
• Attente dans une file d'attente vide : la file d'attente des événements du planificateur est vide, le planificateur est donc en veille

Recommandations d'apprentissage gratuites associées : base de données mysql(vidéo)

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!