Skip navigation links
13.5.3.15 Syntaxe de SHOW STATUS »
Section Navigation      [Toggle]

13.5.3.14. Syntaxe de SHOW PROCESSLIST 

SHOW [FULL] PROCESSLIST

SHOW [FULL] PROCESSLIST affiche la liste de processus qui sont en cours d'exécution. Vous pouvez aussi obtenir ces informations avec la commande en ligne mysqladmin processlist. Si vous avez les droits de SUPER, vous pourrez aussi voir les autres threads. Sinon, vous ne pourrez voir que les votre. See Section 13.5.4.3, « Syntaxe de KILL ». Si vous n'utilisez pas l'option FULL, seuls les 100 premiers caractères de chaque requête seront affichés.

Cette commande est très pratique si vous obtenez trop d'erreurs ‘too many connections’ et que vous voulez savoir ce qui se passe. MySQL réserve une connexion supplémentaire pour un client ayant les droits de SUPER, de fa¸on à ce qu'il y ait toujours la possibilité de se connecter et de vérifier le système (en supposant que vous ne donnez pas ce droit à tous vos utilisateurs).

Certains états sont souvent disponible dans le résultat de mysqladmin processlist

  • Checking table

    Le thread fait une vérification (automatique) de la table.

  • Closing tables

    Le thread est en train d'écrire les données modifiées sur le disque, et il va fermer les tables. Cela doit être une opération très rapide. Si ce n'est pas le cas, vous devriez vérifier si vous n'avez pas un disque plein, ou que le disque est sous haute charge.

  • Connect Out

    Connexion d'un esclave sur le maître.

  • Copying to tmp table on disk

    Le résultat temporaire était plus grand que tmp_table_size et le thread passe d'une table en mémoire à une table sur disque.

  • Creating tmp table

    Le thread est en train de créer une table temporaire pour contenir le résultat d'une requête.

  • deleting from main table

    Lors de l'exécution de la première partie d'une requête d'effacement multi-table, et que MySQL n'a commencé à effacer que dans la première table.

  • deleting from reference tables

    Lors de l'exécution de la deuxième partie d'une requête d'effacement multi-table, et que MySQL a commencé à effacer dans les autres tables.

  • Flushing tables

    Le thread exécute la commande FLUSH TABLES et il attend que tous les threads ferme leur tables.

  • Killed

    Quelqu'un a envoyé une commande KILL et le thread s'annuler la prochaine fois qu'il vérifie l'option de kill. Cette option est vérifiée dans chaque boucle majeure de MySQL, mais dans certains cas, il peut lui prendre un court instant avant de s'arrêter. Si le thread est verrouillé par un autre thread, l'arrêt va prendre effet aussitôt que l'autre thread lève son verrou.

  • Sending data

    Le thread traite des lignes pour une commande SELECT et il envoie les données au client.

  • Sorting for group

    Le thread est en train de faire un tri pour satisfaire une clause GROUP BY.

  • Sorting for order

    Le thread est en train de faire un tri pour satisfaire une clause ORDER BY.

  • Opening tables

    Cela signifie simplement que le thread essaie d'ouvrir une table. Ce doit être une opération très rapide, à moins que quelque chose ne retarde l'ouverture. Par exemple, une commande ALTER TABLE ou LOCK TABLE peut empêcher l'ouverture de table, jusqu'à l'achèvement de la commande.

  • Removing duplicates

    La requête utilisait SELECT DISTINCT de telle manière que MySQL ne pouvait pas optimiser les lignes distinctes au début du traitement. A cause de cela, MySQL doit effectuer une opération de plus pour supprimer toutes les lignes en doubles, avant d'envoyer les lignes au client.

  • Reopen table

    Le thread a re¸u un verrou pour une table, mais a noté après l'avoir re¸u que la structure de la table a changé. Il a libéré le verrou, fermé la table, et maintenant il essaie de la rouvrir.

  • Repair by sorting

    Le thread répare la table en utilisant la méthode de tri pour créer l'index.

  • Repair with keycache

    Le thread répare la table en utilisant la méthode de création des clés à partir du cache de clé. C'est bien plus lent que la réparation par tri.

  • Searching rows for update

    Le thread effectue une première phase pour trouver toutes les lignes qui satisfont les critères avant de les modifier. Cela doit être fait si UPDATE modifie l'index qui sera utilisé pour trouver les lignes.

  • Sleeping

    Le thread attend que le client envoie une nouvelle commande.

  • System lock

    Le thread attend le verrou externe pour la table. Si vous n'utilisez pas de serveurs MySQL multiples qui exploitent les mêmes tables, vous pouvez désactiver les verrous systèmes avec l'option --skip-external-locking.

  • Upgrading lock

    Le gestionnaire de INSERT DELAYED essaie d'obtenir un verrou pour insérer des lignes.

  • Updating

    Le thread recherche des lignes pour les modifier.

  • User Lock

    Le thread attend un GET_LOCK().

  • Waiting for tables

    Le thread a re¸u l'annonce que la structure de table a été modifiée, et il doit réouvrir la table pour obtenir une nouvelle structure. Pour être capable de réouvrir la table, il doit attendre que les autres threads aient fermé la table en question.

    Cette annonce survient lorsqu'un autre autre thread a été utilisé avec la commande FLUSH TABLES ou une des commandes suivantes, appliquées à la table en question : FLUSH TABLES table_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE ou OPTIMIZE TABLE.

  • waiting for handler insert

    Le gestionnaire de INSERT DELAYED a traité toutes insertions, et en attend de nouvelles.

La plupart des états sont des opérations très rapides. Si le thread s'attarde dans un de ces états pour plusieurs secondes, il doit y avoir un problème qui mérite d'être étudié.

Il existe encore d'autres états qui ne sont pas mentionné ci-dessus, mais la majorité sont utilisés pour trouver des bogues dans mysqld.

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.