synch/cond/innodb/row_lock_wait - Amazon Aurora
Unterstützte Engine-VersionenWahrscheinliche Ursachen für erhöhte WartezeitenAktionen

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/cond/innodb/row_lock_wait

Das synch/cond/innodb/row_lock_wait-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:

  • Aurora MySQL Version 3: 3.02.0, 3.02.1, 3.02.2

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:

  • Wenn Zeilensperren ein dauerhaftes Problem darstellen, erwägen Sie, die Anwendung neu zu schreiben, um eine optimistische Sperre zu verwenden.

  • Verwenden Sie mehrzeilige Anweisungen.

  • Verteilen Sie die Workload auf verschiedene Datenbankobjekte. Sie können dazu die Partitionierung verwenden.

  • Prüfen Sie den Wert des innodb_lock_wait_timeout-Parameters. Es steuert, wie lange Transaktionen warten, bevor ein Timeout-Fehler generiert wird.

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 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; 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_engine_transaction_id waiting_transaction,
    ilw.blocking_engine_lock_id blocking_lock,
    il.lock_mode blocking_mode,
    il.lock_type blocking_type,
    ilw.blocking_engine_transaction_id blocking_transaction,
    CASE it.trx_state
        WHEN 'LOCK WAIT'
        THEN it.trx_state
        ELSE p.state end blocker_state,
    concat(il.object_schema,'.', il.object_name) as locked_table,
    it.trx_mysql_thread_id blocker_thread,
    p.user blocker_user,
    p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_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_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G

*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)

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

  • Wenden Sie sich an den Besitzer der Anwendung oder den Benutzer.

  • Wenn die Sperrsitzung im Leerlauf ist, erwägen Sie, die Sperrsitzung zu beenden. Diese Aktion könnte einen langen Rollback auslösen. Informationen zum Beenden einer Sitzung finden Sie unter Beenden einer Sitzung oder Abfrage.

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