Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik terbaik untuk performa dan penskalaan Aurora MySQL

Anda dapat menerapkan praktik terbaik berikut untuk meningkatkan performa dan skalabilitas klaster Aurora MySQL Anda.

Menggunakan kelas instans T untuk pengembangan dan pengujian

Instans Amazon Aurora MySQL yang menggunakan kelas instans DB db.t2, db.t3 atau db.t4g paling cocok untuk aplikasi yang tidak mendukung beban kerja yang tinggi untuk waktu yang lama. Instans T dirancang untuk memberikan performa dasar sedang dan kemampuan untuk melakukan burst performa yang secara signifikan lebih tinggi sesuai dengan yang dibutuhkan beban kerja Anda. Instans ini ditujukan untuk beban kerja yang tidak menggunakan CPU penuh secara sering atau konsisten, tetapi kadang-kadang memerlukan burst. Kami menyarankan penggunaan kelas instans DB T hanya untuk server pengembangan dan pengujian, atau server non-produksi lainnya. Untuk detail selengkapnya tentang kelas instans T, lihat Instans performa yang dapat melonjak.

Jika klaster Aurora Anda lebih besar dari 40 TB, jangan gunakan kelas instans T. Ketika basis data Anda memiliki volume data yang besar, overhead memori untuk mengelola objek skema dapat melebihi kapasitas instans T.

Jangan aktifkan Skema Performa MySQL pada instans T Amazon Aurora MySQL. Jika Skema Performa diaktifkan, instans ini dapat kehabisan memori.

Saat Anda menggunakan instans T sebagai instans DB di klaster DB Aurora MySQL kami menyarankan hal berikut:

Mengoptimalkan kueri join yang diindeks MySQL Aurora dengan prefetch kunci asinkron

Aurora MySQL dapat menggunakan fitur prefetch kunci asinkron (AKP) untuk meningkatkan performa kueri yang menggabungkan tabel di seluruh indeks. Fitur ini meningkatkan performa dengan mengantisipasi baris yang diperlukan untuk menjalankan kueri yang mengharuskan kueri JOIN menggunakan fitur optimisasi Batched Key Access (BKA) dan Multi-Range Read (MRR). Untuk informasi selengkapnya tentang BKA dan MRR, lihat Block nested-loop and batched key access joins dan Multi-range read optimization dalam dokumentasi MySQL.

Untuk memanfaatkan fitur AKP, kueri harus menggunakan BKA dan MRR. Biasanya, kueri tersebut terjadi saat klausa JOIN dari kueri menggunakan indeks sekunder, tetapi juga memerlukan beberapa kolom dari indeks primer. Misalnya, Anda dapat menggunakan AKP ketika klausa JOIN merepresentasikan equijoin pada nilai indeks antara tabel luar kecil dan tabel dalam besar, dan indeksnya sangat selektif pada tabel yang lebih besar. AKP beroperasi bersama dengan BKA dan MRR untuk melakukan pencarian indeks sekunder hingga primer selama evaluasi klausa JOIN. AKP mengidentifikasi baris yang diperlukan untuk menjalankan kueri selama evaluasi klausa JOIN. Kemudian, fitur ini menggunakan thread latar belakang untuk secara asinkron memuat halaman yang berisi baris tersebut ke dalam memori sebelum menjalankan kueri.

AKP tersedia untuk Aurora MySQL versi 2.10 dan lebih tinggi, serta versi 3. Untuk informasi selengkapnya tentang versi Aurora MySQL, lihat Pembaruan mesin database untuk Amazon Aurora My SQL.

Mengaktifkan prefetch kunci asinkron

Anda dapat mengaktifkan fitur AKP dengan mengatur aurora_use_key_prefetch, sebuah variabel server MySQL, ke on. Secara default, nilai ini diatur ke on. Namun, AKP tidak dapat diaktifkan sampai Anda juga mengaktifkan algoritma BKA Join dan menonaktifkan fungsionalitas MRR berbasis biaya. Untuk melakukannya, Anda harus menetapkan nilai berikut untuk optimizer_switch, sebuah variabel server MySQL:

Saat ini, Anda dapat mengatur nilai ini hanya di tingkat sesi. Contoh berikut menggambarkan cara menetapkan nilai-nilai ini untuk mengaktifkan AKP untuk sesi saat ini dengan mengeksekusi pernyataan SET.

mysql> set @@session.aurora_use_key_prefetch=on;
mysql> set @@session.optimizer_switch='batched_key_access=on,mrr_cost_based=off';

Demikian pula, Anda dapat menggunakan pernyataan SET untuk menonaktifkan AKP dan algoritma BKA Join serta mengaktifkan ulang fungsi MRR berbasis biaya untuk sesi saat ini, seperti yang ditunjukkan dalam contoh berikut.

mysql> set @@session.aurora_use_key_prefetch=off;
mysql> set @@session.optimizer_switch='batched_key_access=off,mrr_cost_based=on';

Untuk informasi selengkapnya tentang switch pengoptimisasi batched_key_access dan mrr_cost_based lihat Switchable optimizations dalam dokumentasi MySQL.

Mengoptimalkan kueri untuk prefetch kunci asinkron

Anda dapat mengonfirmasi apakah kueri dapat memanfaatkan fitur AKP. Untuk melakukannya, gunakan pernyataan EXPLAIN untuk membuat profil kueri sebelum menjalankannya. Pernyataan EXPLAIN memberikan informasi tentang rencana eksekusi yang akan digunakan untuk kueri tertentu.

Pada output pernyataan EXPLAIN, kolom Extra menjelaskan informasi tambahan, termasuk rencana eksekusi. Jika fitur AKP berlaku pada tabel yang digunakan dalam kueri, kolom ini mencakup salah satu nilai berikut:

Contoh berikut menunjukkan penggunaan EXPLAIN untuk melihat rencana eksekusi untuk kueri yang dapat memanfaatkan AKP.

mysql> explain select sql_no_cache
    ->     ps_partkey,
    ->     sum(ps_supplycost * ps_availqty) as value
    -> from
    ->     partsupp,
    ->     supplier,
    ->     nation
    -> where
    ->     ps_suppkey = s_suppkey
    ->     and s_nationkey = n_nationkey
    ->     and n_name = 'ETHIOPIA'
    -> group by
    ->     ps_partkey having
    ->         sum(ps_supplycost * ps_availqty) > (
    ->             select
    ->                 sum(ps_supplycost * ps_availqty) * 0.0000003333
    ->             from
    ->                 partsupp,
    ->                 supplier,
    ->                 nation
    ->             where
    ->                 ps_suppkey = s_suppkey
    ->                 and s_nationkey = n_nationkey
    ->                 and n_name = 'ETHIOPIA'
    ->         )
    -> order by
    ->     value desc;
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
| id | select_type | table    | type | possible_keys         | key           | key_len | ref                              | rows | filtered | Extra                                                       |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
|  1 | PRIMARY     | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where; Using temporary; Using filesort                |
|  1 | PRIMARY     | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  1 | PRIMARY     | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
|  2 | SUBQUERY    | nation   | ALL  | PRIMARY               | NULL          | NULL    | NULL                             |   25 |   100.00 | Using where                                                 |
|  2 | SUBQUERY    | supplier | ref  | PRIMARY,i_s_nationkey | i_s_nationkey | 5       | dbt3_scale_10.nation.n_nationkey | 2057 |   100.00 | Using index                                                 |
|  2 | SUBQUERY    | partsupp | ref  | i_ps_suppkey          | i_ps_suppkey  | 4       | dbt3_scale_10.supplier.s_suppkey |   42 |   100.00 | Using join buffer (Batched Key Access with Key Prefetching) |
+----+-------------+----------+------+-----------------------+---------------+---------+----------------------------------+------+----------+-------------------------------------------------------------+
6 rows in set, 1 warning (0.00 sec)

Untuk informasi selengkapnya tentang format output EXPLAIN, lihat Extended EXPLAIN output format dalam dokumentasi MySQL.

Mengoptimalkan kueri join MySQL Aurora besar dengan hash join

Saat Anda harus menggabungkan sejumlah besar data dengan menggunakan equijoin, hash join dapat meningkatkan performa kueri. Anda dapat mengaktifkan hash join untuk Aurora MySQL.

Kolom hash join dapat berupa ekspresi rumit apa pun. Dalam kolom hash join, Anda dapat membandingkan jenis data dengan cara berikut:

Batasan berikut berlaku untuk hash join untuk Aurora MySQL:

Mengaktifkan hash join

Untuk mengaktifkan hash join:

Hash join diaktifkan secara default di Aurora MySQL versi 3 dan dinonaktifkan secara default di Aurora MySQL versi 2. Contoh berikut mengilustrasikan cara mengaktifkan hash join untuk Aurora MySQL versi 3. Anda dapat mengeluarkan pernyataan select @@optimizer_switch terlebih dahulu untuk melihat apa saja pengaturan lain yang ada dalam string parameter SET. Memperbarui satu pengaturan dalam parameter optimizer_switch tidak akan menghapus atau memodifikasi pengaturan lainnya.

mysql> SET optimizer_switch='block_nested_loop=on';

Dengan pengaturan ini, pengoptimisasi memilih untuk menggunakan hash join berdasarkan biaya, karakteristik kueri, dan ketersediaan sumber daya. Jika estimasi biaya salah, Anda dapat memaksa pengoptimisasi untuk memilih hash join. Caranya adalah dengan mengatur hash_join_cost_based, sebuah variabel server MySQL, ke off. Contoh berikut mengilustrasikan cara memaksa pengoptimisasi untuk memilih hash join.

mysql> SET optimizer_switch='hash_join_cost_based=off';

Mengoptimalkan kueri untuk hash join

Untuk mengetahui apakah kueri dapat memanfaatkan hash join, gunakan pernyataan EXPLAIN untuk membuat profil kueri terlebih dahulu. Pernyataan EXPLAIN memberikan informasi tentang rencana eksekusi yang akan digunakan untuk kueri tertentu.

Pada output pernyataan EXPLAIN, kolom Extra menjelaskan informasi tambahan, termasuk rencana eksekusi. Jika hash join berlaku pada tabel yang digunakan dalam kueri, kolom ini akan mencakup nilai seperti yang berikut ini:

Contoh berikut menunjukkan penggunaan EXPLAIN untuk melihat rencana eksekusi untuk kueri hash join.

mysql> explain SELECT sql_no_cache * FROM hj_small, hj_big, hj_big2
    ->     WHERE hj_small.col1 = hj_big.col1 and hj_big.col1=hj_big2.col1 ORDER BY 1;
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra                                                          |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
|  1 | SIMPLE      | hj_small | ALL  | NULL          | NULL | NULL    | NULL |    6 | Using temporary; Using filesort                                |
|  1 | SIMPLE      | hj_big   | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where; Using join buffer (Hash Join Outer table hj_big)  |
|  1 | SIMPLE      | hj_big2  | ALL  | NULL          | NULL | NULL    | NULL |   15 | Using where; Using join buffer (Hash Join Inner table hj_big2) |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------------------------------------------------------+
3 rows in set (0.04 sec)

Dalam output ini, Hash Join Inner table adalah tabel yang digunakan untuk membuat tabel hash, dan Hash Join Outer table adalah tabel yang digunakan untuk menyelidiki tabel hash.

Untuk informasi selengkapnya tentang format output EXPLAIN yang diperluas, lihat Extended EXPLAIN Output Format dalam dokumentasi produk MySQL.

Di Aurora MySQL 2.08 dan yang lebih tinggi, Anda dapat menggunakan petunjuk SQL untuk memengaruhi apakah kueri menggunakan hash join atau tidak, dan tabel mana yang digunakan untuk sisi build dan probe dari join. Untuk detailnya, lihat Aurora Petunjuk saya SQL.

Menggunakan Amazon Aurora untuk menskalakan baca untuk basis data MySQL Anda

Anda dapat menggunakan Amazon Aurora dengan instans DB MySQL Anda untuk memanfaatkan kemampuan penskalaan baca Amazon Aurora dan memperluas beban kerja baca untuk instans DB MySQL Anda. Untuk menggunakan Aurora untuk menskalakan baca instans DB MySQL Anda, buat klaster DB Aurora MySQL dan jadikan sebagai replika baca dari instans DB MySQL Anda. Kemudian, hubungkan ke klaster Aurora MySQL untuk memproses kueri baca. Basis data sumber dapat berupa instans DB RDS for MySQL, atau sebuah basis data MySQL yang dijalankan secara eksternal di luar Amazon RDS. Untuk informasi selengkapnya, lihat Penskalaan bacaan untuk SQL database Saya dengan Amazon Aurora.

Mengoptimalkan operasi stempel waktu

Ketika nilai variabel sistem time_zone diatur ke SYSTEM, setiap panggilan fungsi MySQL yang memerlukan perhitungan zona waktu akan membuat panggilan pustaka sistem. Saat Anda menjalankan pernyataan SQL yang menampilkan atau mengubah nilai TIMESTAMP tersebut pada konkurensi tinggi, Anda mungkin akan mengalami latensi, pertentangan kunci, dan penggunaan CPU yang meningkat. Untuk informasi selengkapnya, lihat time_zone dalam dokumentasi MySQL.

Untuk menghindari perilaku ini, sebaiknya Anda mengubah nilai parameter klaster DB time_zone menjadi UTC. Untuk informasi selengkapnya, lihat Memodifikasi parameter dalam grup parameter cluster DB di Amazon Aurora.

Meskipun parameter time_zone bersifat dinamis (tidak memerlukan pengaktifan ulang server basis data), nilai baru hanya digunakan untuk koneksi baru. Untuk memastikan bahwa semua koneksi diperbarui untuk menggunakan nilai time_zone baru, kami sarankan Anda mendaur ulang koneksi aplikasi Anda setelah memperbarui parameter klaster DB.

Kesalahan luapan ID indeks virtual

Aurora MySQL membatasi nilai untuk indeks virtual IDs hingga 8 bit mencegah masalah yang disebabkan oleh format undo di MySQL. Jika indeks melebihi batas ID indeks virtual, klaster Anda mungkin tidak tersedia. Ketika indeks mendekati batas ID indeks virtual atau ketika Anda mencoba membuat indeks di atas batas ID indeks virtual, RDS mungkin membuang kode kesalahan 63955 atau kode 63955 peringatan. Untuk mengatasi kesalahan batas ID indeks virtual, kami sarankan Anda membuat ulang database Anda dengan dump dan restore logis.

Untuk informasi selengkapnya tentang dump logis dan restore untuk Amazon Aurora MySQL, lihat Memigrasikan database yang sangat besar ke Amazon Aurora MySQL menggunakan dan. MyDumper MyLoader Untuk informasi selengkapnya tentang mengakses log kesalahan di Amazon Aurora, lihat. Memantau log Amazon Aurora Amazon