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

Praktik terbaik untuk SQL kinerja dan penskalaan Aurora My

Anda dapat menerapkan praktik terbaik berikut untuk meningkatkan kinerja dan skalabilitas cluster Aurora SQL My Anda.

Menggunakan kelas instans T untuk pengembangan dan pengujian

Amazon Aurora My SQL instans yang menggunakandb.t2,db.t3, atau kelas instans db.t4g DB paling cocok untuk aplikasi yang tidak mendukung beban kerja 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. Mereka dimaksudkan untuk beban kerja yang tidak CPU sering digunakan secara penuh atau konsisten, tetapi kadang-kadang perlu meledak. 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 SQL Kinerja Saya di Amazon Aurora SQL My T instans. Jika Skema Performa diaktifkan, instans ini dapat kehabisan memori.

Saat Anda menggunakan instans T sebagai instans DB di cluster Aurora My SQL DB, kami merekomendasikan hal berikut:

Mengoptimalkan Aurora Kueri gabungan SQL saya yang diindeks dengan prefetch kunci asinkron

Aurora My SQL dapat menggunakan fitur asynchronous key prefetch (AKP) untuk meningkatkan kinerja kueri yang menggabungkan tabel di seluruh indeks. Fitur ini meningkatkan kinerja dengan mengantisipasi baris yang diperlukan untuk menjalankan kueri di mana JOIN kueri memerlukan penggunaan algoritma Batched Key Access (BKA) Join dan fitur pengoptimalan Multi-Range Read (MRR). Untuk informasi selengkapnya tentang BKA danMRR, lihat Memblokir sambungan akses kunci bersarang dan pengoptimalan baca multi-rentang dalam dokumentasi Saya. SQL

Untuk memanfaatkan AKP fitur ini, kueri harus menggunakan keduanya BKA danMRR. Biasanya, kueri seperti itu terjadi ketika JOIN klausa kueri menggunakan indeks sekunder, tetapi juga membutuhkan beberapa kolom dari indeks utama. Misalnya, Anda dapat menggunakan AKP ketika JOIN klausa mewakili ekuijoin pada nilai indeks antara tabel dalam luar kecil dan besar, dan indeks sangat selektif pada tabel yang lebih besar. AKPbekerja bersama dengan BKA dan MRR untuk melakukan pencarian indeks sekunder ke primer selama evaluasi JOIN klausa. AKPmengidentifikasi baris yang diperlukan untuk menjalankan kueri selama evaluasi JOIN klausa. Kemudian, fitur ini menggunakan thread latar belakang untuk secara asinkron memuat halaman yang berisi baris tersebut ke dalam memori sebelum menjalankan kueri.

AKPtersedia untuk Aurora My SQL versi 2.10 dan lebih tinggi, dan versi 3. Untuk informasi lebih lanjut tentang Aurora SQL versi Saya, lihat. Pembaruan mesin database untuk Amazon Aurora My SQL

Mengaktifkan prefetch kunci asinkron

Anda dapat mengaktifkan AKP fitur dengan mengaturaurora_use_key_prefetch, variabel SQL server Saya, keon. Secara default, nilai ini diatur ke on. Namun, tidak AKP dapat diaktifkan sampai Anda juga mengaktifkan algoritma BKA Gabung dan menonaktifkan fungsionalitas berbasis biayaMRR. Untuk melakukannya, Anda harus menetapkan nilai berikut untukoptimizer_switch, variabel SQL server Saya:

Saat ini, Anda dapat mengatur nilai ini hanya di tingkat sesi. Contoh berikut menggambarkan bagaimana mengatur nilai-nilai ini AKP untuk mengaktifkan sesi saat ini dengan mengeksekusi pernyataanSET.

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 SET pernyataan untuk menonaktifkan AKP dan algoritma BKA Join dan mengaktifkan kembali MRR fungsionalitas berbasis biaya untuk sesi saat ini, seperti yang ditunjukkan pada 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 sakelar pengoptimal batched_key_access dan mrr_cost_based, lihat Pengoptimalan yang dapat dialihkan dalam dokumentasi Saya. SQL

Mengoptimalkan kueri untuk prefetch kunci asinkron

Anda dapat mengonfirmasi apakah kueri dapat memanfaatkan AKP fitur tersebut. 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 AKP fitur ini berlaku untuk tabel yang digunakan dalam kueri, kolom ini mencakup salah satu nilai berikut:

Contoh berikut menunjukkan penggunaan EXPLAIN untuk melihat rencana eksekusi untuk query yang dapat mengambil keuntungan dariAKP.

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 EXPLAIN output, lihat Extended EXPLAIN output format dalam SQL dokumentasi Saya.

Mengoptimalkan Aurora besar Kueri bergabung SQL saya dengan gabungan hash

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

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

Pembatasan berikut berlaku untuk bergabung dengan hash untuk Aurora My: SQL

Mengaktifkan hash join

Untuk mengaktifkan hash join:

Gabungan hash diaktifkan secara default di Aurora My SQL versi 3 dan dimatikan secara default di Aurora My version 2. SQL Contoh berikut menggambarkan cara mengaktifkan gabungan hash untuk Aurora My versi 3. SQL 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. Anda melakukannya dengan mengaturhash_join_cost_based, variabel SQL server Saya, keoff. 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 query bergabung hash.

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 EXPLAIN keluaran yang diperluas, lihat Format EXPLAIN Output Diperpanjang dalam dokumentasi SQL produk saya.

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

Menggunakan Amazon Aurora untuk menskalakan bacaan untuk database Saya SQL

Anda dapat menggunakan Amazon Aurora dengan instans My SQL DB Anda untuk memanfaatkan kemampuan penskalaan baca Amazon Aurora dan memperluas beban kerja baca untuk instans DB Saya. SQL Untuk menggunakan Aurora untuk membaca skala instans My SQL DB Anda, buat cluster Aurora My SQL DB dan jadikan replika baca instans My DB Anda. SQL Kemudian sambungkan ke SQL cluster Aurora My untuk memproses kueri baca. Database sumber dapat berupa RDS instans SQL DB Saya, atau SQL database Saya yang berjalan di luar AmazonRDS. Untuk informasi selengkapnya, lihat Penskalaan bacaan untuk SQL database Saya dengan Amazon Aurora.

Mengoptimalkan operasi stempel waktu

Ketika nilai variabel sistem time_zone diatur keSYSTEM, setiap panggilan SQL fungsi Saya yang memerlukan perhitungan zona waktu membuat panggilan perpustakaan sistem. Saat Anda menjalankan SQL pernyataan yang mengembalikan atau mengubah TIMESTAMP nilai tersebut pada konkurensi tinggi, Anda mungkin mengalami peningkatan latensi, pertentangan kunci, dan penggunaan. CPU Untuk informasi selengkapnya, lihat time_zone dalam dokumentasi SayaSQL.

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.