Aurora Mon SQL fil de discussion indique

Le thread vérifie si le serveur dispose des privilèges requis pour exécuter l'instruction.

Le serveur vérifie si la requête actuelle est présente dans le cache de requête.

Il s'agit de l'état final d'une connexion dont la tâche est terminée, mais qui n'a pas été fermée par le client. La meilleure solution consiste à fermer explicitement la connexion dans le code. Vous pouvez également définir une valeur inférieure pour wait_timeout dans votre groupe de paramètres.

Le thread vide les données de table modifiées sur le disque et ferme les tables utilisées. Si l'opération se prolonge, vérifiez les métriques de consommation de bande passante réseau par rapport à la bande passante réseau de classe d'instance. Vérifiez également que les valeurs des paramètres pour table_open_cacheet table_definition_cache permettent d'ouvrir simultanément un nombre suffisant de tables pour éviter au moteur de devoir ouvrir et fermer fréquemment les tables. Ces paramètres ont une incidence sur la consommation de mémoire sur l'instance.

La requête convertit une table temporaire de table en mémoire à table sur disque. Cette conversion est nécessaire car les tables temporaires créées par My SQL au cours des étapes intermédiaires du traitement des requêtes sont devenues trop volumineuses pour la mémoire. Vérifiez les valeurs de tmp_table_size et max_heap_table_size. Dans les versions ultérieures, ce nom d'état de thread estconverting HEAP to ondisk.

Le thread convertit une table temporaire interne de table en mémoire à table sur disque.

Le thread traite une instruction ALTER TABLE. Cet état intervient après la création de la table avec la nouvelle structure, mais avant que des lignes n'y soient copiées. En présence d'un thread dans cet état, vous pouvez utiliser le schéma de performance pour obtenir des informations relatives à la progression de l'opération de copie.

Aurora My SQL effectue un tri car il ne peut pas utiliser un index existant pour satisfaire la GROUP BY clause ORDER BY or d'une requête. Pour de plus amples informations, veuillez consulter creating sort index.

Le thread crée une table permanente ou temporaire.

Un commit asynchrone dans Aurora My SQL a reçu un accusé de réception et est terminé.

Le SQL thread Aurora My a lancé le processus de validation asynchrone mais attend un accusé de réception. Il s'agit généralement du moment auquel une transaction est validée.

Un SQL thread de travail Aurora My lié à une connexion peut être libéré pendant qu'une réponse est envoyée au client. Le thread peut entamer d'autres tâches. L'état delayed send ok signifie que l'accusé de réception asynchrone adressé au client est terminé.

Un SQL thread de travail Aurora My a envoyé une réponse de manière asynchrone à un client et est désormais libre de travailler pour d'autres connexions. La transaction a lancé un processus de validation asynchrone qui n'a pas encore été confirmé.

Le thread a commencé à exécuter une instruction.

Le thread a exécuté une commande. La libération de certains éléments durant cet état implique le cache de requête. Cet état est généralement suivi d'un nettoyage.

Cet état intervient avant l'initialisation des instructions ALTER TABLE, DELETE, INSERT, SELECT ou UPDATE. Les actions correspondant à cet état incluent le vidage du journal binaire ou du journal InnoDB, et le nettoyage du cache de requête.

Le nœud primaire a terminé sa part de la réplication. Le thread attend l'exécution d'autres requêtes pour pouvoir écrire dans le journal binaire (binlog).

Le thread essaie d'ouvrir une table. Cette opération est rapide, sauf si une instruction ALTER TABLE ou LOCK TABLEdoit se terminer, ou si elle dépasse la valeur de table_open_cache.

Le serveur effectue des optimisations initiales pour une requête.

Cet état intervient lors de l'optimisation des requêtes.

Cet état intervient après le traitement d'une requête, mais avant l'état de libération des éléments.

Aurora My SQL n'a pas pu optimiser une DISTINCT opération au début d'une requête. Aurora My SQL doit supprimer toutes les lignes dupliquées avant d'envoyer le résultat au client.

Le thread recherche toutes les lignes correspondantes avant de les mettre à jour. Cette étape est nécessaire si la UPDATE modifie l'index utilisé par le moteur pour trouver les lignes.

Le thread lit un événement à partir du journal binaire et l'envoie au réplica.

Le serveur extrait le résultat d'une requête du cache de requête et l'envoie au client.

Le thread lit et traite les lignes d'une instruction SELECT, mais n'a pas encore commencé à envoyer des données au client. Le processus consiste à identifier les pages qui contiennent les résultats nécessaires pour satisfaire la requête. Pour de plus amples informations, veuillez consulter envoi de données.

Le serveur écrit un paquet sur le client. Dans les SQL versions antérieures de My, cet événement d'attente était étiquetéwriting to net.

Il s'agit de la première étape intervenant au début de l'exécution de l'instruction.

Le serveur calcule des statistiques pour développer un plan d'exécution des requêtes. Si un thread perdure dans cet état, le serveur est probablement lié au disque pendant qu'il effectue d'autres tâches.

Le serveur stocke le résultat d'une requête dans le cache de requête.

Le thread a appelé mysql_lock_tables, mais l'état du thread n'a pas été mis à jour depuis l'appel. Cet état général intervient pour de nombreuses raisons.

Le thread se prépare à commencer à mettre à jour la table.

Le thread recherche des lignes et les met à jour.

Le thread a émis un appel GET_LOCK. Le thread a demandé un verrou consultatif et l'attend, ou envisage de le demander.

Le nœud primaire a terminé sa part de la réplication. Le thread attend l'exécution d'autres requêtes pour pouvoir écrire dans le journal binaire (binlog).

Il s'agit de l'attente d'un verrou de métadonnées.

Il s'agit de l'attente d'un verrou de métadonnées.

Il s'agit de l'attente d'un verrou de métadonnées.

Le thread exécute FLUSH TABLES et attend que tous les threads de ferment leurs tables. Ou bien, le thread a reçu une notification indiquant que la structure sous-jacente d'une table a changé et qu'il lui faut rouvrir cette table pour obtenir la nouvelle structure. Pour rouvrir cette table, le thread doit attendre que tous les autres threads l'aient fermée. Cette notification intervient si un autre thread a utilisé une des instructions suivantes sur la table : FLUSH TABLES, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE ou OPTIMIZE TABLE.

Une session maintient un verrou sur une table tandis qu'une autre tente d'acquérir le même verrou sur la même table.

Aurora My SQL utilise le verrouillage des métadonnées pour gérer l'accès simultané aux objets de base de données et pour garantir la cohérence des données. Dans cet événement d'attente, une session maintient un verrou de métadonnées sur une table tandis qu'une autre tente d'acquérir le même verrou sur la même table. Lorsque le schéma de performance est activé, cet état de thread est signalé en tant qu'événement d'attente synch/cond/sql/MDL_context::COND_wait_status.

Le serveur écrit un paquet sur le réseau. Dans les SQL versions ultérieures de My, cet événement d'attente est étiquetéSending to client.