Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# synch/cond/innodb/row\$1lock\$1tunggu
Peristiwa `synch/cond/innodb/row_lock_wait` terjadi ketika satu sesi telah mengunci baris untuk pembaruan dan sesi lain mencoba memperbarui baris yang sama. Untuk informasi selengkapnya, lihat [penguncian InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) di dokumentasi MySQL.
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 3
## Kemungkinan penyebab peningkatan peristiwa tunggu
Beberapa pernyataan bahasa manipulasi data (DML) mengakses baris atau sejumlah baris yang sama secara serentak.
## Tindakan
Kami merekomendasikan berbagai tindakan, tergantung pada peristiwa tunggu lain yang Anda lihat.
**Topics**
+ [
### Menemukan dan merespons pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini
](#ams-waits.row-lock-wait.actions.id)
+ [
### Menemukan dan merespons sesi pemblokiran
](#ams-waits.row-lock-wait.actions.blocker)
### Menemukan dan merespons pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini
Gunakan Wawasan Performa untuk mengidentifikasi pernyataan SQL yang bertanggung jawab atas peristiwa tunggu ini. Pertimbangkan strategi berikut:
+ Jika kunci baris merupakan masalah yang terus-menerus, coba tulis ulang aplikasi untuk menggunakan penguncian optimis.
+ Gunakan pernyataan multibaris.
+ Bagikan beban kerja ke objek basis data yang berbeda-beda. Anda dapat melakukannya melalui partisi.
+ Periksa nilai parameter `innodb_lock_wait_timeout`. Parameter ini mengontrol durasi transaksi menunggu sebelum menghasilkan kesalahan batas waktu.
Untuk ikhtisar pemecahan masalah yang berguna menggunakan Wawasan Performa, lihat postingan blog [Menganalisis Beban Kerja Amazon Aurora MySQL dengan Wawasan Performa](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Menemukan dan merespons sesi pemblokiran
Cari tahu apakah sesi pemblokiran idle atau aktif. Cari tahu juga apakah sesi tersebut berasal dari aplikasi atau pengguna aktif.
Untuk mengidentifikasi sesi yang memegang kunci, Anda dapat menjalankan `SHOW ENGINE INNODB STATUS`. Contoh berikut menunjukkan output sampel.
```
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
```
Sebagai alternatif, Anda dapat menggunakan kueri berikut untuk mengekstrak detail tentang kunci saat ini.
```
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)
```
Saat mengidentifikasi sesi, opsi Anda mencakup yang berikut:
+ Menghubungi pemilik aplikasi atau pengguna.
+ Jika sesi pemblokiran idle, coba akhiri sesi pemblokiran. Tindakan ini dapat memicu rollback yang panjang. Untuk mempelajari cara mengakhiri sesi, lihat [Mengakhiri sesi atau kueri](mysql-stored-proc-ending.md).
Untuk informasi selengkapnya tentang mengidentifikasi transaksi pemblokiran, lihat [Menggunakan transaksi InnoDB dan mengunci informasi dalam dokumentasi](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html) MySQL.