Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# io/table/sql/handler
Peristiwa `io/table/sql/handler` terjadi ketika pekerjaan telah didelegasikan ke mesin penyimpanan.
**Topics**
+ [Versi mesin yang didukung](#ams-waits.waitio.context.supported)
+ [Konteks](#ams-waits.waitio.context)
+ [Kemungkinan penyebab peningkatan peristiwa tunggu](#ams-waits.waitio.causes)
+ [Tindakan](#ams-waits.waitio.actions)
## Versi mesin yang didukung
Informasi peristiwa tunggu ini didukung untuk versi mesin berikut:
+ Aurora MySQL versi 2 dan 3
## Konteks
Peristiwa `io/table` menunjukkan peristiwa tunggu untuk akses ke tabel. Peristiwa ini terjadi terlepas dari apakah data di-cache di pool buffer atau diakses pada disk. Peristiwa `io/table/sql/handler` menunjukkan peningkatan aktivitas beban kerja.
*Handler* adalah rutinitas yang berspesialisasi dalam jenis data tertentu atau berfokus pada tugas khusus tertentu. Misalnya, handler peristiwa menerima dan mencerna peristiwa serta sinyal dari sistem operasi atau antarmuka pengguna. Handler memori melakukan tugas-tugas yang berkaitan dengan memori. Handler input file adalah fungsi yang menerima input file dan melakukan tugas khusus pada data, sesuai dengan konteksnya.
Tampilan seperti `performance_schema.events_waits_current` sering kali menunjukkan `io/table/sql/handler` ketika peristiwa tunggu sebenarnya adalah peristiwa tunggu bersarang seperti penguncian. Jika peristiwa tunggu sebenarnya bukan `io/table/sql/handler`, Wawasan Performa akan melaporkan peristiwa tunggu bersarang. Saat Performance Insights melaporkan`io/table/sql/handler`, ini mewakili pemrosesan I/O permintaan InnoDB dan bukan peristiwa tunggu bersarang yang tersembunyi. Untuk informasi selengkapnya, lihat [Peristiwa Atom dan Molekul Skema Performa](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) dalam *Panduan Referensi MySQL*.
`io/table/sql/handler`Acara ini sering muncul di acara tunggu teratas dengan I/O menunggu seperti`io/aurora_redo_log_flush`.
## Kemungkinan penyebab peningkatan peristiwa tunggu
Dalam Wawasan Performa, lonjakan mendadak dalam peristiwa `io/table/sql/handler` menunjukkan adanya peningkatan aktivitas beban kerja. Peningkatan aktivitas berarti peningkatan I/O.
Performance Insights memfilter peristiwa bersarang IDs dan tidak melaporkan `io/table/sql/handler` penantian saat peristiwa bersarang yang mendasarinya adalah menunggu kunci. Misalnya, jika peristiwa akar penyebabnya adalah [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), Wawasan Performa akan menampilkan peristiwa tunggu ini dalam peristiwa tunggu teratas, bukan `io/table/sql/handler`.
Dalam tampilan seperti `performance_schema.events_waits_current`, peristiwa tunggu untuk `io/table/sql/handler` sering kali muncul ketika peristiwa tunggu sebenarnya adalah peristiwa tunggu bersarang seperti penguncian. Jika peristiwa tunggu sebenarnya berbeda dengan `io/table/sql/handler`, Wawasan Performa akan mencari peristiwa tunggu bersarang dan melaporkan peristiwa tunggu sebenarnya, bukan `io/table/sql/handler`. Saat Wawasan Performa melaporkan `io/table/sql/handler`, peristiwa tunggu sebenarnya adalah `io/table/sql/handler`, bukan peristiwa tunggu bersarang yang tersembunyi. Untuk informasi selengkapnya, lihat [Peristiwa Atom dan Molekul Skema Performa](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) dalam *Panduan Referensi MySQL 5.7*.
## Tindakan
Jika peristiwa tunggu ini mendominasi aktivitas basis data, hal tersebut tidak selalu menunjukkan adanya masalah performa. Peristiwa tunggu selalu berada di atas saat basis data aktif. Anda perlu melakukan tindakan hanya bila performa menurun.
Kami merekomendasikan berbagai tindakan, tergantung pada peristiwa tunggu lain yang Anda lihat.
**Topics**
+ [Mengidentifikasi sesi dan kueri penyebab peristiwa](#ams-waits.waitio.actions.identify)
+ [Memeriksa korelasi dengan metrik penghitung Wawasan Performa](#ams-waits.waitio.actions.filters)
+ [Memeriksa peristiwa tunggu berkorelasi lainnya](#ams-waits.waitio.actions.maintenance)
### Mengidentifikasi sesi dan kueri penyebab peristiwa
Biasanya, basis data dengan beban sedang hingga signifikan memiliki peristiwa tunggu. Peristiwa tunggu ini mungkin dapat diterima jika basis data berperforma optimal. Jika tidak, periksa di mana basis data tersebut menghabiskan waktu terbanyak. Lihat peristiwa tunggu yang berkontribusi ke beban tertinggi, lalu cari tahu apakah Anda dapat mengoptimalkan basis data dan aplikasi untuk mengurangi peristiwa tersebut.
**Untuk menemukan kueri SQL yang bertanggung jawab atas beban tinggi:**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Wawasan Performa**.
1. Pilih instans DB. Dasbor Wawasan Performa ditampilkan untuk instans DB tersebut.
1. Dalam bagan **Beban basis data**, pilih **Potong berdasarkan masa tunggu**.
1. Di bagian bawah halaman, pilih **SQL Teratas**.
Bagan ini mencantumkan kueri SQL yang bertanggung jawab atas beban. Kueri di bagian atas daftar memiliki tanggung jawab terbesar. Untuk mengatasi kemacetan, fokus pada pernyataan tersebut.
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/).
### Memeriksa korelasi dengan metrik penghitung Wawasan Performa
Periksa metrik penghitung Wawasan Performa seperti `Innodb_rows_changed`. Jika metrik penghitung berkorelasi dengan `io/table/sql/handler`, ikuti langkah-langkah berikut:
1. Dalam Wawasan Performa, cari pernyataan SQL yang memperhitungkan peristiwa tunggu teratas `io/table/sql/handler`. Jika memungkinkan, optimalkan pernyataan ini sehingga mengembalikan lebih sedikit baris.
1. Ambil tabel teratas dari tampilan `schema_table_statistics` dan `x$schema_table_statistics`. Tampilan ini menunjukkan jumlah waktu yang dihabiskan per tabel. Untuk informasi selengkapnya, lihat [Tampilan schema\$1table\$1statistics dan x\$1schema\$1table\$1statistics](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) dalam *Panduan Referensi MySQL*.
Secara default, baris diurutkan berdasarkan total waktu tunggu menurun. Tabel dengan pertentangan terbanyak ditampilkan terlebih dahulu. Output menunjukkan apakah waktu dihabiskan untuk membaca, menulis, mengambil, menyisipkan, memperbarui, atau menghapus.
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### Memeriksa peristiwa tunggu berkorelasi lainnya
Jika `synch/sxlock/innodb/btr_search_latch` dan `io/table/sql/handler` bersama-sama berkontribusi paling besar terhadap anomali beban DB, periksa apakah variabel `innodb_adaptive_hash_index` diaktifkan. Jika ya, coba tingkatkan nilai parameter `innodb_adaptive_hash_index_parts`.
Jika Adaptive Hash Index dinonaktifkan, coba untuk mengaktifkannya. Untuk mempelajari selengkapnya tentang Adaptive Hash Index MySQL, lihat sumber daya berikut:
+ Artikel [Is Adaptive Hash Index in InnoDB right for my workload?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload) di situs web Percona
+ [Adaptive Hash Index](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html) dalam *Panduan Referensi MySQL*
+ Artikel [Contention in MySQL InnoDB: Useful Info From the Semaphores Section](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/) di situs web Percona
**catatan**
Adaptive Hash Index tidak didukung pada instans DB pembaca Aurora.
Dalam kasus tertentu, performa mungkin buruk pada instans pembaca saat `synch/sxlock/innodb/btr_search_latch` dan `io/table/sql/handler` bersifat dominan. Jika demikian, coba alihkan beban kerja sementara ke instans DB penulis dan aktifkan Adaptive Hash Index.