Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah kinerja kueri untuk database Aurora MySQL
MySQL [menyediakan kontrol pengoptimal kueri](https://dev.mysql.com/doc/refman/8.0/en/controlling-optimizer.html) melalui variabel sistem yang memengaruhi cara rencana kueri dievaluasi, pengoptimalan yang dapat dialihkan, petunjuk pengoptimal dan indeks, dan model biaya pengoptimal. Titik data ini dapat membantu tidak hanya saat membandingkan lingkungan MySQL yang berbeda, tetapi juga untuk membandingkan rencana eksekusi kueri sebelumnya dengan rencana eksekusi saat ini, dan untuk memahami eksekusi keseluruhan kueri MySQL kapan saja.
Kinerja kueri tergantung pada banyak faktor, termasuk rencana eksekusi, skema tabel dan ukuran, statistik, sumber daya, indeks, dan konfigurasi parameter. Penyetelan kueri memerlukan identifikasi kemacetan dan mengoptimalkan jalur eksekusi.
+ Temukan rencana eksekusi untuk kueri dan periksa apakah kueri menggunakan indeks yang sesuai. Anda dapat mengoptimalkan kueri Anda dengan menggunakan `EXPLAIN` dan meninjau detail setiap paket.
+ Aurora MySQL versi 3 (kompatibel dengan MySQL 8.0 Community Edition) menggunakan pernyataan. `EXPLAIN ANALYZE` `EXPLAIN ANALYZE`Pernyataan ini adalah alat profil yang menunjukkan di mana MySQL menghabiskan waktu pada kueri Anda dan mengapa. Dengan`EXPLAIN ANALYZE`, Aurora MySQL merencanakan, menyiapkan, dan menjalankan kueri sambil menghitung baris dan mengukur waktu yang dihabiskan di berbagai titik rencana eksekusi. Saat kueri selesai, `EXPLAIN ANALYZE` mencetak rencana dan pengukurannya, bukan hasil kueri.
+ Perbarui statistik skema Anda dengan menggunakan `ANALYZE` pernyataan. Pengoptimal kueri terkadang dapat memilih rencana eksekusi yang buruk karena statistik yang sudah ketinggalan zaman. Hal ini dapat menyebabkan kinerja kueri yang buruk karena perkiraan kardinalitas yang tidak akurat dari tabel dan indeks. `last_update`Kolom tabel [innodb\$1table\$1stats](https://dev.mysql.com/doc/refman/8.0/en/innodb-persistent-stats.html#innodb-persistent-stats-tables) menunjukkan terakhir kali statistik skema Anda diperbarui, yang merupakan indikator “kebuntuan” yang baik.
+ Masalah lain dapat terjadi, seperti kemiringan distribusi data, yang tidak diperhitungkan untuk kardinalitas tabel. Untuk informasi selengkapnya, lihat [Memperkirakan kompleksitas TABEL ANALISIS untuk tabel InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-analyze-table-complexity.html) [dan statistik Histogram di MySQL dalam dokumentasi](https://dev.mysql.com/blog-archive/histogram-statistics-in-mysql/) MySQL.
## Memahami waktu yang dihabiskan oleh pertanyaan
Berikut ini adalah cara untuk menentukan waktu yang dihabiskan oleh kueri:
+ [Pembuatan profil](https://dev.mysql.com/doc/refman/8.0/en/show-profile.html)
+ [Skema Kinerja](https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html)
+ [Pengoptimal kueri](https://dev.mysql.com/doc/refman/8.0/en/controlling-optimizer.html)
**Pembuatan profil**
Secara default, pembuatan profil dinonaktifkan. Aktifkan pembuatan profil, lalu jalankan kueri lambat dan tinjau profilnya.
```
SET profiling = 1;
Run your query.
SHOW PROFILE;
```
1. Identifikasi tahap di mana waktu paling banyak dihabiskan. Menurut [status utas Umum](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html) dalam dokumentasi MySQL, membaca dan memproses baris untuk pernyataan seringkali merupakan status `SELECT` yang paling lama berjalan selama masa kueri yang diberikan. Anda dapat menggunakan `EXPLAIN` pernyataan untuk memahami bagaimana MySQL menjalankan kueri ini.
1. Tinjau log kueri lambat `rows_sent` untuk mengevaluasi `rows_examined` dan memastikan bahwa beban kerja serupa di setiap lingkungan. Untuk informasi selengkapnya, lihat [Logging untuk database MySQL Aurora](aurora-mysql-troubleshooting-logging.md).
1. Jalankan perintah berikut untuk tabel yang merupakan bagian dari kueri yang diidentifikasi:
```
SHOW TABLE STATUS\G;
```
1. Tangkap output berikut sebelum dan sesudah menjalankan kueri di setiap lingkungan:
```
SHOW GLOBAL STATUS;
```
1. Jalankan perintah berikut di setiap lingkungan untuk melihat apakah ada hal lain yang query/session mempengaruhi kinerja kueri sampel ini.
```
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\G;
```
Terkadang, ketika sumber daya di server sibuk, itu berdampak pada setiap operasi lain di server, termasuk kueri. Anda juga dapat menangkap informasi secara berkala saat kueri dijalankan atau menyiapkan `cron` pekerjaan untuk menangkap informasi pada interval yang berguna.
**Skema Performa**
Skema Kinerja memberikan informasi yang berguna tentang kinerja runtime server, sementara memiliki dampak minimal pada kinerja itu. Ini berbeda dari`information_schema`, yang menyediakan informasi skema tentang instans DB. Untuk informasi selengkapnya, lihat [Ikhtisar Skema Kinerja untuk Performance Insights di Aurora ](USER_PerfInsights.EnableMySQL.md).
**Jejak pengoptimal kueri**
Untuk memahami mengapa [rencana kueri tertentu dipilih untuk dieksekusi](https://dev.mysql.com/doc/refman/8.0/en/execution-plan-information.html), Anda dapat mengatur `optimizer_trace` untuk mengakses pengoptimal kueri MySQL.
Jalankan jejak pengoptimal untuk menampilkan informasi ekstensif tentang semua jalur yang tersedia untuk pengoptimal dan pilihannya.
```
SET SESSION OPTIMIZER_TRACE="enabled=on";
SET optimizer_trace_offset=-5, optimizer_trace_limit=5;
-- Run your query.
SELECT * FROM table WHERE x = 1 AND y = 'A';
-- After the query completes:
SELECT * FROM information_schema.OPTIMIZER_TRACE;
SET SESSION OPTIMIZER_TRACE="enabled=off";
```
## Meninjau pengaturan pengoptimal kueri
Aurora MySQL versi 3 (kompatibel dengan MySQL 8.0 Community Edition) memiliki banyak perubahan terkait pengoptimalan dibandingkan dengan Aurora MySQL versi 2 (kompatibel dengan MySQL 5.7 Community Edition). Jika Anda memiliki beberapa nilai kustom untuk`optimizer_switch`, kami sarankan Anda meninjau perbedaan default dan menetapkan `optimizer_switch` nilai yang paling sesuai untuk beban kerja Anda. Kami juga menyarankan Anda menguji opsi yang tersedia untuk Aurora MySQL versi 3 untuk memeriksa kinerja kueri Anda.
**catatan**
[Aurora MySQL versi 3 menggunakan nilai default komunitas 20 untuk parameter innodb\$1stats\$1persistent\$1sample\$1pages.](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_stats_persistent_sample_pages)
Anda dapat menggunakan perintah berikut untuk menunjukkan `optimizer_switch` nilai-nilai:
```
SELECT @@optimizer_switch\G;
```
Tabel berikut menunjukkan `optimizer_switch` nilai default untuk Aurora MySQL versi 2 dan 3.
| Pengaturan | Aurora MySQL versi 2 | Aurora MySQL versi 3 |
| --- | --- | --- |
| batched\$1key\$1access | off | off |
| block\$1nested\$1loop | on | on |
| condition\$1fanout\$1filter | on | on |
| derived\$1condition\$1pushdown | – | on |
| derived\$1merge | on | on |
| duplicateweedout | on | on |
| engine\$1condition\$1pushdown | on | on |
| firstmatch | on | on |
| hash\$1join | off | on |
| hash\$1join\$1cost\$1based | on | – |
| hypergraph\$1optimizer | – | off |
| index\$1condition\$1pushdown | on | on |
| index\$1merge | on | on |
| index\$1merge\$1intersection | on | on |
| index\$1merge\$1sort\$1union | on | on |
| index\$1merge\$1union | on | on |
| loosescan | on | on |
| materialization | on | on |
| mrr | on | on |
| mrr\$1cost\$1based | on | on |
| prefer\$1ordering\$1index | on | on |
| semijoin | on | on |
| skip\$1scan | – | on |
| subquery\$1materialization\$1cost\$1based | on | on |
| subquery\$1to\$1derived | – | off |
| use\$1index\$1extensions | on | on |
| use\$1invisible\$1indexes | – | off |
Untuk informasi selengkapnya, lihat [Pengoptimalan yang dapat dialihkan (MySQL 5.7) dan [pengoptimalan Switchable](https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html) (MySQL 8.0)](https://dev.mysql.com/doc/refman/5.7/en/switchable-optimizations.html) dalam dokumentasi MySQL.