Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

synch/mutex/innodb/aurora_lock_thread_slot_futex

Das synch/mutex/innodb/aurora_lock_thread_slot_futex-Ereignis tritt auf, wenn eine Sitzung eine Zeile für ein Update gesperrt hat und eine andere Sitzung versucht, dieselbe Zeile zu aktualisieren. Weitere Informationen finden Sie unter InnoDB-Sperren in der MySQL-Referenz.

Unterstützte Engine-Versionen

Diese Warteereignisinformationen werden für die folgenden Engine-Versionen unterstützt:

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Mehrere DML-Anweisungen (Data Manipulation Language) greifen gleichzeitig auf dieselbe Zeile oder dieselben Zeilen zu.

Aktionen

Abhängig von den anderen angezeigten Warteereignissen empfehlen wir unterschiedliche Aktionen.

Finden und antworten Sie auf die SQL-Anweisungen, die für dieses Warteereignis verantwortlich sind

Verwenden Sie Performance Insights, um die SQL-Anweisungen zu identifizieren, die für dieses Warteereignis verantwortlich sind. Berücksichtigen Sie dabei die folgenden Strategien:

Eine nützliche Übersicht über die Fehlerbehebung mit Performance Insights finden Sie im Blogbeitrag Analysieren Sie Amazon Aurora MySQL Workloads mit Performance Insights.

Suchen und antworten Sie auf die Blockiersitzung

Stellen Sie fest, ob die Blockiersitzung im Leerlauf oder aktiv ist. Finden Sie außerdem heraus, ob die Sitzung von einer Anwendung oder einem aktiven Benutzer stammt.

Um die Sitzung zu identifizieren, die die Sperre hält, können Sie SHOW ENGINE INNODB STATUS ausführen. Das folgende Beispiel zeigt eine Beispielausgabe.

mysql> SHOW ENGINE INNODB STATUS;

---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0

Oder Sie können die folgende Abfrage verwenden, um Details zu aktuellen Sperren zu extrahieren.

mysql> SELECT p1.id waiting_thread,
              p1.user waiting_user,
              p1.host waiting_host,
              it1.trx_query waiting_query,        
              ilw.requesting_trx_id waiting_transaction, 
              ilw.blocking_lock_id blocking_lock, 
              il.lock_mode blocking_mode,
              il.lock_type blocking_type,
              ilw.blocking_trx_id blocking_transaction,
              CASE it.trx_state 
                WHEN 'LOCK WAIT' 
                THEN it.trx_state 
                ELSE p.state 
              END blocker_state, 
              il.lock_table locked_table,        
              it.trx_mysql_thread_id blocker_thread, 
              p.user blocker_user, 
              p.host blocker_host 
       FROM information_schema.innodb_lock_waits ilw 
       JOIN information_schema.innodb_locks il 
         ON ilw.blocking_lock_id = il.lock_id 
        AND ilw.blocking_trx_id = il.lock_trx_id
       JOIN information_schema.innodb_trx it 
         ON ilw.blocking_trx_id = it.trx_id
       JOIN information_schema.processlist p 
         ON it.trx_mysql_thread_id = p.id 
       JOIN information_schema.innodb_trx it1 
         ON ilw.requesting_trx_id = it1.trx_id 
       JOIN information_schema.processlist p1 
         ON it1.trx_mysql_thread_id = p1.id\G

*************************** 1. row ***************************
      waiting_thread: 3561959471
        waiting_user: reinvent
        waiting_host: 123.456.789.012:20485
       waiting_query: select id1 from test.t1 where id1=1 for update
 waiting_transaction: 312337314
       blocking_lock: 312337287:261:3:2
       blocking_mode: X
       blocking_type: RECORD
blocking_transaction: 312337287
       blocker_state: User sleep
        locked_table: `test`.`t1`
      blocker_thread: 3561223876
        blocker_user: reinvent
        blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)

Wenn Sie die Sitzung identifizieren, umfassen Ihre Optionen die Folgenden:

Weitere Informationen zum Identifizieren blockierender Transaktionen finden Sie unter Verwenden von InnoDB-Transaktions- und Sperrinformationen im MySQL-Referenzhandbuch.