Zeigt alle aktuellen Sperren von get

Ab MySQL 5.7 ist dies möglich, erfordert aber zuerst die Aktivierung von mdl instrument im performance_schema.setup_instruments Tisch. Sie können dies vorübergehend tun (bis der Server das nächste Mal neu gestartet wird), indem Sie Folgendes ausführen:

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

Oder dauerhaft, indem Sie die folgende Beschwörung zu [mysqld] hinzufügen Abschnitt Ihrer my.cnf Datei (oder welche Konfigurationsdateien auch immer MySQL aus Ihrer Installation liest):

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

(Natürlich muss MySQL neu gestartet werden, damit die Konfigurationsänderung wirksam wird, wenn Sie den letzteren Ansatz wählen.)

Schlösser, die Sie nach entfernen die mdl Instrument aktiviert wurde, kann durch Ausführen eines SELECT angezeigt werden gegen performance_schema.metadata_locks Tisch. Wie in der Dokumentation angegeben, GET_LOCK Sperren haben einen OBJECT_TYPE von 'USER LEVEL LOCK' , sodass wir unsere Abfrage mit einem WHERE nach unten filtern können Klausel:

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>

Die Bedeutung der Spalten in diesem Ergebnis ist größtenteils angemessen dokumentiert unter https://dev.mysql.com/doc/refman/en/metadata-locks-table.html , aber ein Punkt der Verwirrung ist erwähnenswert:die OWNER_THREAD_ID Spalte nicht enthalten die Verbindung ID (wie sie in der PROCESSLIST angezeigt würde oder von CONNECTION_ID() zurückgegeben ) des Threads, der die Sperre hält. Verwirrenderweise wird der Begriff „Thread-ID“ in der MySQL-Dokumentation manchmal als Synonym für „Verbindungs-ID“ verwendet, aber das ist nicht eine dieser Zeiten. Wenn Sie die Verbindung ermitteln möchten ID der Verbindung, die eine Sperre hält (zum Beispiel, um diese Verbindung mit KILL ), müssen Sie die PROCESSLIST_ID nachschlagen das entspricht der THREAD_ID in performance_schema.threads Tisch. Zum Beispiel, um die Verbindung zu beenden, die meine Sperre oben gehalten hat...

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)

Zeigt alle aktuellen Sperren von get_lock