Mysql
 sql >> Base de données >  >> RDS >> Mysql

Afficher tous les verrous actuels de get_lock

A partir de MySQL 5.7, cela est possible, mais nécessite d'abord d'activer le mdl instrument dans performance_schema.setup_instruments table. Vous pouvez le faire temporairement (jusqu'au prochain redémarrage du serveur) en exécutant :

UPDATE performance_schema.setup_instruments
SET enabled = 'YES'
WHERE name = 'wait/lock/metadata/sql/mdl';

Ou de façon permanente, en ajoutant l'incantation suivante au [mysqld] section de votre my.cnf fichier (ou tout autre fichier de configuration que MySQL lit sur votre installation) :

[mysqld]
performance_schema_instrument = 'wait/lock/metadata/sql/mdl=ON'

(Naturellement, MySQL devra être redémarré pour que le changement de configuration prenne effet si vous adoptez cette dernière approche.)

Les cadenas que vous enlevez après le mdl l'instrument a été activé peut être vu en exécutant un SELECT contre les performance_schema.metadata_locks table. Comme indiqué dans la documentation, GET_LOCK les serrures ont un OBJECT_TYPE de 'USER LEVEL LOCK' , afin que nous puissions filtrer notre requête jusqu'à eux avec un WHERE clause :

mysql> SELECT GET_LOCK('foobarbaz', -1);
+---------------------------+
| GET_LOCK('foobarbaz', -1) |
+---------------------------+
|                         1 |
+---------------------------+
1 row in set (0.00 sec)

mysql> SELECT * FROM performance_schema.metadata_locks 
    -> WHERE OBJECT_TYPE='USER LEVEL LOCK'
    -> \G
*************************** 1. row ***************************
          OBJECT_TYPE: USER LEVEL LOCK
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: foobarbaz
OBJECT_INSTANCE_BEGIN: 139872119610944
            LOCK_TYPE: EXCLUSIVE
        LOCK_DURATION: EXPLICIT
          LOCK_STATUS: GRANTED
               SOURCE: item_func.cc:5482
      OWNER_THREAD_ID: 35
       OWNER_EVENT_ID: 3
1 row in set (0.00 sec)

mysql> 

Les significations des colonnes de ce résultat sont pour la plupart documentées de manière adéquate sur https://dev.mysql.com/doc/refman/en/metadata-locks-table.html , mais un point de confusion mérite d'être noté :le OWNER_THREAD_ID la colonne ne fait pas contenir la connexion ID (comme serait affiché dans la PROCESSLIST ou renvoyé par CONNECTION_ID() ) du thread qui maintient le verrou. De manière confuse, le terme "ID de thread" est parfois utilisé comme synonyme de "ID de connexion" dans la documentation MySQL, mais ce n'est pas une de ces fois. Si vous voulez déterminer la connexion ID de la connexion qui détient un verrou (par exemple, pour tuer cette connexion avec KILL ), vous devrez rechercher le PROCESSLIST_ID qui correspond au THREAD_ID dans le performance_schema.threads table. Par exemple, pour tuer la connexion qui retenait mon cadenas au-dessus...

mysql> SELECT OWNER_THREAD_ID FROM performance_schema.metadata_locks
    -> WHERE OBJECT_TYPE='USER LEVEL LOCK'
    -> AND OBJECT_NAME='foobarbaz';
+-----------------+
| OWNER_THREAD_ID |
+-----------------+
|              35 |
+-----------------+
1 row in set (0.00 sec)

mysql> SELECT PROCESSLIST_ID FROM performance_schema.threads
    -> WHERE THREAD_ID=35;
+----------------+
| PROCESSLIST_ID |
+----------------+
|             10 |
+----------------+
1 row in set (0.00 sec)

mysql> KILL 10;
Query OK, 0 rows affected (0.00 sec)