Cara menggunakan mysql restore deleted rows

Berikut ini, Anda dapat menemukan deskripsi pengoptimalan kinerja kueri paralel untuk Amazon Aurora Edisi Kompatibel MySQL. Fitur ini menggunakan jalur pemrosesan khusus untuk kueri tertentu yang sarat data, memanfaatkan arsitektur penyimpanan bersama Aurora. Kueri paralel sangat cocok digunakan dengan klaster DB Aurora MySQL yang memiliki tabel dengan jutaan baris dan kueri analitik yang memerlukan waktu beberapa menit atau jam untuk diselesaikan. Untuk informasi tentang versi Aurora MySQL yang mendukung kueri parallel diAWSWilayah, lihatKueri paralel Aurora.

Daftar Isi

• Ikhtisar kueri paralel untuk Aurora MySQL
  • ManfaatIT
  • Arsitektur
  • Prasyarat
  • Keterbatasan:
• Merencanakan klaster kueri paralel
  • Memeriksa kompatibilitas versi Aurora MySQL untuk kueri paralel
• Membuat klaster DB yang bekerja dengan kueri paralel
  • Membuat klaster kueri paralel menggunakan konsol
  • Membuat klaster kueri paralel menggunakan CLI
• Menghidupkan dan mematikan kueri parallel
  • Aurora MySQL 1.23 dan 2.09 atau lebih tinggi
  • Sebelum Aurora MySQL 1.23
  • Mengaktifkan hash join untuk klaster kueri parallel
  • Menghidupkan dan mematikan kueri parallel menggunakan konsol
  • Menghidupkan dan mematikan kueri parallel menggunakan CLI
• Pertimbangan peningkatan untuk kueri paralel
  • Upgrade cluster query parallel ke Aurora MySQL versi 3
  • Men-upgrade ke Aurora MySQL 1.23 atau 2.09 dan versi lebih tinggi
• Penyempurnaan kinerja untuk kueri paralel
• Membuat objek skema untuk memanfaatkan kueri paralel
• Memverifikasi pernyataan mana yang menggunakan kueri paralel
• Memantau kueri paralel
• Cara kerja kueri paralel dengan konstruksi SQL
  • Pernyataan EXPLAIN
  • Klausul WHERE
  • Bahasa definisi data (DDL)
  • Jenis data kolom
  • Tabel yang dipartisi
  • Fungsi agregat, klausul GROUP BY, dan klausul HAVING
  • Panggilan fungsi dalam klausul WHERE
  • Klausul LIMIT
  • Operator perbandingan
  • Bergabung
  • Subkueri
  • UNION
  • Tampilan
  • Pernyataan bahasa manipulasi data (DML)
  • Transaksi dan penguncian
  • Indeks pohon B
  • Indeks pencarian teks penuh (FTS)
  • Kolom virtual
  • Mekanisme caching bawaan
  • Tabel sementara MyISAM

Ikhtisar kueri paralel untuk Aurora MySQL

Kueri paralel Aurora MySQL adalah pengoptimalan yang memaralelkan beberapa I/O dan komputasi yang termasuk dalam pemrosesan kueri sarat data. Pekerjaan yang diparalelkan mencakup mengambil baris dari penyimpanan, mengekstraksi nilai kolom, dan menentukan baris mana yang cocok dengan ketentuan dalam klausul WHERE dan klausul gabungan. Pekerjaan sarat data ini didelegasikan (dalam istilah pengoptimalan basis data, diturunkan) ke beberapa simpul di lapisan penyimpanan terdistribusi Aurora. Tanpa kueri paralel, setiap kueri membawa semua data yang dipindai ke simpul tunggal dalam Aurora MySQL klaster (simpul kepala) dan melakukan semua pemrosesan kueri di sana.

Mesin database PostgreSQL juga memiliki fitur yang disebut "kueri paralel". Fitur tersebut tidak terkait dengan kueri paralel Aurora.

Saat fitur kueri parallel diaktifkan, mesin Aurora MySQL secara otomatis menentukan kapan kueri dapat menguntungkan, tanpa memerlukan perubahan SQL seperti petunjuk atau atribut tabel. Pada bagian berikut, Anda dapat menemukan penjelasan tentang kapan kueri paralel diterapkan pada kueri. Anda juga dapat menemukan cara memastikan bahwa kueri paralel diterapkan di tempat yang memberi banyak keuntungan.

Pengoptimalan kueri paralel sangat menguntungkan bagi kueri yang berlangsung lama yang memerlukan waktu beberapa menit atau jam hingga selesai. Aurora MySQL umumnya tidak melakukan pengoptimalan kueri paralel untuk kueri yang murah. Aurora juga umumnya tidak melakukan pengoptimalan kueri paralel jika teknik pengoptimalan lain lebih masuk akal, seperti query caching, buffer pool caching, atau pencarian indeks. Jika Anda menemukan kueri paralel yang tidak digunakan seperti yang Anda perkirakan, lihat Memverifikasi pernyataan mana yang menggunakan kueri paralel.

ManfaatIT

Dengan kueri paralel, Anda dapat menjalankan kueri analitik sarat data pada tabel Aurora MySQL. Dalam banyak kasus, Anda bisa mendapatkan order-of-magnitude peningkatan kinerja melalui divisi kerja tradisional untuk pemrosesan kueri.

Manfaat kueri paralel mencakup hal-hal berikut:

• Peningkatan kinerja I/O, karena paralelisasi permintaan baca fisik lintas beberapa simpul penyimpanan.

• Mengurangi lalu lintas jaringan. Aurora tidak mengirim keseluruhan halaman data dari simpul penyimpanan ke simpul kepala lalu memfilter baris dan kolom yang tidak diperlukan sesudahnya. Sebaliknya, Aurora mengirim urutan ringkas yang berisi nilai kolom yang diperlukan untuk set hasil.

• Mengurangi penggunaan CPU pada simpul kepala, karena menurunkan pemrosesan fungsi, penyaringan baris, dan proyeksi kolom untuk klausul WHERE.

• Menurunkan tekanan memori pada buffer pool. Halaman yang diproses oleh kueri paralel tidak ditambahkan ke dalam buffer pool. Pendekatan ini mengurangi peluang pemindaian sarat data agar tidak mengeluarkan data yang sering digunakan dari buffer pool.

• Kemungkinan berkurangnya duplikasi data dalam ekstrak, transformasi, saluran beban (ETL) Anda, dengan memudahkannya untuk melakukan kueri analitik yang berlangsung lama pada data yang sudah ada.

Arsitektur

Fitur kueri paralel menggunakan prinsip arsitektur utama Aurora MySQL: memisahkan mesin basis data dari subsistem penyimpanan, dan mengurangi lalu lintas jaringan dengan menyederhanakan protokol komunikasi. Aurora MySQL menggunakan teknik ini untuk mempercepat operasi sarat penulisan seperti mengulangi pemrosesan log. Kueri paralel menerapkan prinsip yang sama untuk operasi membaca.

Arsitektur kueri paralel Aurora MySQL berbeda dari arsitektur dengan nama yang mirip di sistem database lain. Kueri paralel Aurora MySQL tidak mencakup multipemrosesan simetris (SMP) sehingga tidak bergantung pada kapasitas CPU server database. Pemrosesan paralel terjadi di lapisan penyimpanan, terpisah dari server Aurora MySQL yang berfungsi sebagai koordinator kueri.

Secara default, tanpa kueri paralel, pemrosesan untuk kueri Aurora mencakup pengiriman data mentah ke satu simpul dalam klaster Aurora (simpul kepala). Aurora kemudian melakukan semua pemrosesan lebih lanjut untuk kueri tersebut dalam utas tunggal pada satu simpul itu. Dengan kueri paralel, sebagian besar pekerjaan yang sarat I/O dan CPU ini didelegasikan ke simpul dalam lapisan penyimpanan. Hanya baris ringkas set hasil yang dikirim kembali ke simpul kepala, dengan baris yang sudah difilter, dan nilai kolom sudah diekstraksi dan ditransformasikan. Kinerja yang baik berasal dari pengurangan lalu lintas jaringan, pengurangan penggunaan CPU di simpul kepala, dan paralelisasi I/O di seluruh simpul penyimpanan. Jumlah I/O paralel, pemfilteran, dan proyeksi tidak berhubungan dengan jumlah instans DB dalam klaster Aurora yang menjalankan kueri.

Prasyarat

Untuk menggunakan semua fitur kueri paralel memerlukan klaster DB Aurora MySQL yang menjalankan versi 1.23 atau 2.09 dan lebih tinggi. Jika sudah memiliki klaster yang ingin Anda gunakan dengan kueri parallel, Anda dapat meningkatkannya ke versi yang kompatibel dan mengaktifkan kueri parallel sesudahnya. Dalam hal ini, pastikan untuk mengikuti prosedur peningkatan dalam Pertimbangan peningkatan untuk kueri paralel karena nama pengaturan konfigurasi dan nilai default berbeda di versi yang lebih baru ini.

Anda juga dapat menggunakan kueri paralel dengan Aurora MySQL lama versi tertentu yang kompatibel dengan MySQL 5.6: 1.22.2, 1.20.1, 1.19.6, dan 5.6.10a. Dukungan kueri paralel untuk versi yang lebih lama ini hanya tersedia di beberapa Wilayah AWS tertentu. Versi lama tersebut memiliki batasan tambahan, yang dijelaskan sebagai berikut. Menggunakan kueri paralel Aurora MySQL versi lama juga memerlukan pembuatan klaster DB khusus dengan parameter mode mesin khusus yang tidak dapat diubah nanti. Karena alasan tersebut, kami menyarankan penggunaan kueri paralel dengan Aurora MySQL 1.23 atau 2.09 dan versi lebih tinggi jika memungkinkan.

Instans DB dalam klaster Anda harus menggunakan kelas instans db.r*.

Pastikan bahwa pengoptimalan hash join dinyalakan untuk klaster Anda. Prosedur untuk melakukannya berbeda-beda tergantung apakah klaster Anda menjalankan Aurora MySQL versi lebih tinggi atau lebih rendah dari 1.23 atau 2.09. Untuk mempelajari caranya, lihat Mengaktifkan hash join untuk klaster kueri parallel.

Untuk menyesuaikan parameter seperti aurora_parallel_query dan aurora_disable_hash_join, Anda harus memiliki grup parameter kustom yang Anda gunakan untuk klaster Anda. Anda dapat menentukan parameter ini secara terpisah untuk setiap instans DB menggunakan grup parameter DB. Namun, kami menyarankan Anda untuk menetapkannya dalam grup parameter klaster DB. Dengan demikian, semua instans DB di klaster Anda menerima pengaturan yang sama untuk parameter ini.

Keterbatasan:

Batasan berikut berlaku untuk fitur kueri paralel:

• Anda tidak dapat menggunakan kueri paralel dengan kelas instans db.t2 atau db.t3. Batasan ini berlaku bahkan jika Anda meminta kueri paralel menggunakan petunjuk SQL aurora_pq_force.

• Kueri paralel tidak berlaku pada tabel menggunakan format baris COMPRESSED atau REDUNDANT. Gunakan format baris COMPACT atau DYNAMIC untuk tabel yang akan Anda gunakan dengan kueri paralel.

• Aurora menggunakan algoritme berbasis biaya untuk menentukan apakah akan menggunakan mekanisme kueri paralel untuk setiap pernyataan SQL. Menggunakan konstruksi SQL tertentu dalam pernyataan dapat mencegah kueri paralel atau menjadikan kueri paralel tidak memungkinkan untuk pernyataan tersebut. Untuk informasi tentang kompatibilitas konstruksi SQL dengan kueri paralel, lihat Cara kerja kueri paralel dengan konstruksi SQL.

• Setiap instans DB Aurora dapat menjalankan sesi kueri paralel hanya dalam jumlah tertentu pada satu waktu. Jika kueri memiliki beberapa bagian yang menggunakan kueri paralel, seperti subkueri, gabungan, atau operator UNION, fase-fase tersebut berjalan secara berurutan. Pernyataan ini hanya dihitung sebagai satu sesi kueri paralel pada satu waktu. Anda dapat memantau jumlah sesi aktif menggunakan variabel status kueri paralel. Anda dapat memeriksa batas sesi serentak untuk instans DB tertentu dengan melakukan kueri variabel status Aurora_pq_max_concurrent_requests.

• Kueri paralel tersedia di semua Wilayah AWS yang didukung Aurora. Untuk sebagian besar Wilayah AWS, versi minimum Aurora MySQL yang diperlukan untuk menggunakan kueri paralel adalah 1.23 atau 2.09. Untuk informasi selengkapnya, lihat Kueri paralel Aurora.

• Aurora MySQL 1.22.2, 1.20.1, 1.19.6, dan 5.6.10a saja: Menggunakan kueri paralel dengan versi lama ini mencakup pembuatan klaster baru, atau pemulihan dari klaster Aurora MySQL yang sudah ada.

• Aurora MySQL 1.22.2, 1.20.1, 1.19.6, dan 5.6.10a saja: Kueri paralel tidak mendukungAWS Identity and Access ManagementAutentikasi database (IAM).

Merencanakan klaster kueri paralel

Perencanaan untuk klaster DB yang kueri parallel diaktifkan memerlukan beberapa pilihan. Hal ini termasuk melakukan langkah pengaturan (membuat atau memulihkan klaster Aurora MySQL penuh) dan memutuskan seberapa luas pengaktiran kueri parallel di seluruh klaster DB Anda.

Pertimbangkan hal berikut sebagai bagian dari perencanaan:

• Aurora MySQL versi mana yang akan Anda gunakan untuk klaster? Bergantung pada pilihan Anda, Anda dapat menggunakan salah satu cara ini untuk mengaktifkan kueri parallel untuk klaster:

  Jika Anda menggunakan Aurora MySQL yang kompatibel dengan MySQL 5.7, Anda harus memilih Aurora MySQL 2.09 atau versi lebih tinggi. Dalam hal ini, Anda selalu membuat klaster yang disediakan. Kemudian Anda mengaktifkan kueri parallel menggunakan kueri paralel menggunakanaurora_parallel_queryparameter. Kami menyarankan pilihan ini jika Anda memulai kueri paralel Aurora untuk pertama kalinya.

  Jika Anda menggunakan Aurora MySQL yang kompatibel dengan MySQL 5.6, Anda dapat memilih versi 1.23 atau versi tertentu yang lebih rendah. Dengan versi 1.23 atau yang lebih tinggi, Anda membuat klaster yang disediakan lalu mengaktifkan kueri parallel menggunakanaurora_parallel_queryParameter kluster DB. Dengan versi yang lebih rendah dari 1.23, Anda memilih mode mesin parallelquery saat membuat klaster. Dalam hal ini, kueri paralel diaktifkan secara permanen untuk klaster tersebut. Mode mesin parallelquery menerapkan batasan tentang interoperasi dengan jenis lain dari klaster Aurora MySQL. Jika Anda memiliki pilihan, kami sarankan untuk memilih versi 1.23 atau lebih tinggi untuk Aurora MySQL dengan kompatibilitas MySQL 5.6.

  Jika Anda memiliki klaster Aurora MySQL yang menjalankan versi 1.23 atau lebih tinggi, atau 2.09 atau lebih tinggi, Anda tidak perlu membuat klaster baru untuk menggunakan kueri paralel. Anda dapat mengaitkan klaster Anda, atau instans DB tertentu dalam klaster, dengan grup parameter yang memilikiaurora_parallel_queryparameter diaktifkan. Dengan melakukannya, Anda dapat mengurangi waktu dan upaya untuk mengatur data yang relevan untuk digunakan dengan kueri paralel.

• Rencanakan setiap tabel besar yang perlu Anda atur ulang agar Anda dapat menggunakan kueri paralel saat mengaksesnya. Anda mungkin perlu membuat versi baru dari beberapa tabel besar di mana kueri paralel akan bermanfaat. Misalnya, Anda mungkin perlu menghapus indeks pencarian teks penuh. Untuk detail, lihat Membuat objek skema untuk memanfaatkan kueri paralel.

Memeriksa kompatibilitas versi Aurora MySQL untuk kueri paralel

Untuk memeriksa Aurora MySQL versi mana yang kompatibel dengan klaster kueri paralel, gunakan perintah describe-db-engine-versions AWS CLI dan periksa nilai bidang SupportsParallelQuery. Contoh kode berikut menunjukkan cara memeriksa kombinasi mana yang tersedia untuk klaster kueri paralel di Wilayah AWS tertentu. Pastikan untuk menentukan string parameter --query secara lengkap pada satu baris.

aws rds describe-db-engine-versions --region us-east-1 --engine aurora --query '*[]|[?SupportsParallelQuery == `true`].[EngineVersion]' --output text

aws rds describe-db-engine-versions --region us-east-1 --engine aurora-mysql --query '*[]|[?SupportsParallelQuery == `true`].[EngineVersion]' --output text

Perintah sebelumnya menghasilkan output yang serupa dengan yang berikut ini. Output dapat bervariasi tergantung pada Aurora MySQL versi mana yang tersedia di Wilayah AWS tertentu.

5.6.10a
5.6.mysql_aurora.1.19.0
5.6.mysql_aurora.1.19.1
5.6.mysql_aurora.1.19.2
5.6.mysql_aurora.1.19.3
5.6.mysql_aurora.1.19.3.1
5.6.mysql_aurora.1.19.3.90
5.6.mysql_aurora.1.19.4
5.6.mysql_aurora.1.19.4.1
5.6.mysql_aurora.1.19.4.2
5.6.mysql_aurora.1.19.4.3
5.6.mysql_aurora.1.19.4.4
5.6.mysql_aurora.1.19.4.5
5.6.mysql_aurora.1.19.5
5.6.mysql_aurora.1.19.5.90
5.6.mysql_aurora.1.19.6
5.6.mysql_aurora.1.20.1
5.6.mysql_aurora.1.22.0
5.6.mysql_aurora.1.22.2
5.6.mysql_aurora.1.23.0

5.7.mysql_aurora.2.09.0

Setelah mulai menggunakan kueri paralel dengan suatu klaster, Anda dapat memantau kinerja dan menghilangkan kendala pada penggunaan kueri paralel. Untuk instruksi langkah demi langkah, lihat Penyempurnaan kinerja untuk kueri paralel.

Membuat klaster DB yang bekerja dengan kueri paralel

Untuk membuat klaster Aurora MySQL dengan kueri paralel, menambahkan instans baru ke dalamnya, atau melakukan operasi administratif lainnya, Anda menggunakan teknik AWS Management Console dan AWS CLI yang sama seperti yang Anda lakukan dengan klaster Aurora MySQL lainnya. Anda dapat membuat klaster baru untuk bekerja dengan kueri paralel. Anda juga dapat membuat klaster DB untuk bekerja dengan kueri paralel dengan memulihkan dari snapshot klaster DB Aurora yang kompatibel dengan MySQL. Jika Anda tidak memahami proses pembuatan klaster Aurora MySQL, Anda dapat menemukan informasi latar belakang dan prasyaratnya dalam Membuat klaster Amazon Aurora DB.

Namun, terdapat beberapa opsi berbeda:

• Saat Anda memilih versi mesin Aurora MySQL, kami sarankan Anda memilih mesin terbaru yang kompatibel dengan MySQL 5.7. Saat ini, Aurora MySQL 2.09 atau versi lebih tinggi, dan Aurora MySQL versi tertentu yang kompatibel dengan MySQL 5.6 mendukung kueri paralel. Anda memiliki fleksibilitas lebih untuk mengaktifkan dan menonaktifkan kueri paralel, atau menggunakan kueri paralel dengan klaster yang ada, jika Anda menggunakan Aurora MySQL 1.23 atau 2.09 dan versi lebih tinggi.

• Hanya untuk Aurora MySQL sebelum versi 1.23: Saat Anda membuat atau memulihkan klaster DB, pastikan untuk memilih mode mesin kueri paralel.

Dengan membuat klaster baru atau memulihkan dari snapshot, Anda menggunakan teknik yang sama untuk menambahkan instans DB baru yang Anda lakukan dengan klaster Aurora MySQL lainnya.

Membuat klaster kueri paralel menggunakan konsol

Anda dapat membuat klaster kueri paralel baru dengan konsol seperti dijelaskan berikut ini.

Untuk membuat klaster kueri paralel dengan AWS Management Console

1. Ikuti prosedur AWS Management Console umum dalam Membuat klaster Amazon Aurora DB.

2. Pada layar Pilih mesin, pilih Aurora MySQL.

   Untuk Versi mesin, pilih Aurora MySQL versi 2.09 atau lebih tinggi, atau Aurora MySQL versi 1.23 atau lebih tinggi jika memungkinkan. Dengan versi tersebut, Anda memiliki batasan paling sedikit pada penggunaan kueri paralel. Versi tersebut juga memiliki fleksibilitas terbaik untuk mengaktifkan atau menonaktifkan kueri paralel kapan saja.

   Jika tidak memungkinkan untuk menggunakan Aurora MySQL versi terbaru untuk klaster ini, pilih Tampilkan versi yang mendukung fitur kueri paralel. Melakukan hal tersebut akan memfilter menu Versi untuk menampilkan hanya versi Aurora MySQL khusus yang kompatibel dengan kueri paralel.

3. (Hanya untuk versi lama) Untuk Jenis kapasitas, pilih Disediakan dengan kueri paralel Aurora yang diaktifkan. AWS Management Console hanya menampilkan pilihan ini saat Anda memilih Aurora MySQL dalam versi yang lebih rendah dari 1.23. Untuk Aurora MySQL 1.23 atau 2.09 dan versi lebih tinggi, Anda tidak perlu menentukan pilihan khusus agar klaster kompatibel dengan kueri paralel.

4. (Hanya untuk versi terbaru) Untuk Konfigurasi tambahan, pilih grup parameter yang Anda buat untuk Grup parameter klaster DB. Penggunaan grup parameter kustom tersebut diperlukan untuk Aurora MySQL 1.23 atau 2.09 atau 3.1 dan versi lebih tinggi. Di grup parameter klaster DB Anda, tentukan pengaturan parameter aurora_parallel_query=ON dan aurora_disable_hash_join=OFF. Melakukannya akan mengaktifkan kueri parallel untuk klaster, dan mengaktifkan pengoptimalan gabungan hash yang bekerja dalam kombinasi dengan kueri parallel.

Untuk memverifikasi bahwa klaster baru dapat menggunakan kueri paralel

1. Buat klaster menggunakan teknik sebelumnya.

2. (Untuk Aurora MySQL versi 2.09 dan versi minor yang lebih tinggi, atau Aurora MySQL versi 3) Periksa bahwaaurora_parallel_querypengaturan konfigurasi benar.

   mysql> select @@aurora_parallel_query;
   +-------------------------+
   | @@aurora_parallel_query |
   +-------------------------+
   |                       1 |
   +-------------------------+
   

3. (Untuk Aurora MySQL versi 2.09 dan versi minor yang lebih tinggi) Periksa bahwaaurora_disable_hash_joinpengaturan adalah palsu.

   mysql> select @@aurora_disable_hash_join;
   +----------------------------+
   | @@aurora_disable_hash_join |
   +----------------------------+
   |                          0 |
   +----------------------------+
   

4. (Hanya untuk versi lama) Periksa apakah pengaturan konfigurasi aurora_pq_supported benar.

   mysql> select @@aurora_pq_supported;
   +-----------------------+
   | @@aurora_pq_supported |
   +-----------------------+
   |                     1 |
   +-----------------------+
   

5. Dengan beberapa tabel besar dan kueri sarat data, periksa rencana kueri untuk mengonfirmasi bahwa beberapa kueri Anda menggunakan pengoptimalan kueri paralel. Untuk melakukannya, ikuti prosedur di Memverifikasi pernyataan mana yang menggunakan kueri paralel.

Membuat klaster kueri paralel menggunakan CLI

Anda dapat membuat klaster kueri paralel baru dengan CLI seperti yang dijelaskan berikut ini.

Untuk membuat klaster kueri paralel dengan AWS CLI

1. (Opsional) Centang versi Aurora MySQL mana yang kompatibel dengan klaster kueri paralel. Untuk melakukannya, gunakan perintah describe-db-engine-versions dan periksa nilai bidang SupportsParallelQuery. Sebagai contoh, lihat Memeriksa kompatibilitas versi Aurora MySQL untuk kueri paralel.

2. (Opsional) Buat grup parameter klaster DB kustom dengan pengaturan aurora_parallel_query=ON dan aurora_disable_hash_join=OFF. Gunakan perintah seperti berikut ini.

   aws rds create-db-cluster-parameter-group --db-parameter-group-family aurora-mysql5.7 --db-cluster-parameter-group-name pq-enabled-57-compatible
   aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name pq-enabled-57-compatible \
     --parameters ParameterName=aurora_parallel_query,ParameterValue=ON,ApplyMethod=pending-reboot
   aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name pq-enabled-57-compatible \
     --parameters ParameterName=aurora_disable_hash_join,ParameterValue=OFF,ApplyMethod=pending-reboot
   

   Jika Anda melakukan langkah ini, tentukan opsi --db-cluster-parameter-group-name my_cluster_parameter_group dalam pernyataan create-db-cluster selanjutnya. Ganti nama grup parameter Anda. Jika menghapus langkah ini, Anda membuat grup parameter dan mengaitkannya dengan klaster di lain waktu, seperti dijelaskan di Menghidupkan dan mematikan kueri parallel.

3. Ikuti prosedur AWS CLI umum dalam Membuat klaster Amazon Aurora DB.

4. Tentukan rangkaian opsi berikut:

   • Untuk opsi --engine, gunakan aurora atau aurora-mysql. Nilai ini menghasilkan klaster kueri paralel yang kompatibel dengan MySQL 5.6 atau MySQL 5.7 masing-masing.

   • Nilai yang digunakan untuk parameter --engine-mode bergantung pada versi mesin yang Anda pilih.

     Untuk Aurora MySQL 1.23 atau lebih tinggi, atau 2.09 atau lebih tinggi, tentukan --engine-mode provisioned. Anda juga dapat menghilangkan parameter --engine-mode, karena provisioned adalah default. Dalam versi ini, Anda dapat mengaktifkan atau menonaktifkan kueri paralel untuk jenis default klaster Aurora MySQL, alih-alih membuat klaster yang didedikasikan untuk selalu menggunakan kueri paralel.

     Sebelum Aurora MySQL 1.23, untuk pilihan --engine-mode, gunakan parallelquery. Parameter --engine-mode berlaku untuk operasi create-db-cluster. Kemudian mode mesin pada klaster digunakan secara otomatis oleh operasi create-db-instance berikutnya.

   • Untuk pilihan --db-cluster-parameter-group-name, tentukan nama grup parameter klaster DB yang Anda buat dan tentukan nilai parameter aurora_parallel_query=ON. Jika Anda menghilangkan pilihan ini, Anda dapat membuat klaster dengan kelompok parameter default, kemudian memodifikasinya untuk menggunakan grup parameter khusus tersebut.

   • Untuk pilihan --engine-version, gunakan versi Aurora MySQL yang kompatibel dengan kueri paralel. Gunakan prosedur dari Merencanakan klaster kueri paralel untuk mendapatkan daftar versi jika diperlukan. Jika memungkinkan, gunakan setidaknya 1.23.0 atau 2.09.0. Versi ini dan semua versi yang lebih tinggi berisi peningkatan substansial untuk kueri paralel.

     Contoh kode berikut menunjukkan cara melakukannya. Ganti nilai Anda sendiri untuk setiap variabel lingkungan seperti $CLUSTER_ID.

     aws rds create-db-cluster --db-cluster-identifier $CLUSTER_ID--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.09.0 \
       --master-username $MASTER_USER_ID --master-user-password $MASTER_USER_PW \
       --db-cluster-parameter-group-name $CUSTOM_CLUSTER_PARAM_GROUP
     
     aws rds create-db-cluster --db-cluster-identifier $CLUSTER_ID
       --engine aurora --engine-version 5.6.mysql_aurora.1.23.0 \
       --master-username $MASTER_USER_ID --master-user-password $MASTER_USER_PW \
       --db-cluster-parameter-group-name $CUSTOM_CLUSTER_PARAM_GROUP
     
     aws rds create-db-instance --db-instance-identifier ${INSTANCE_ID}-1 \
       --engine same_value_as_in_create_cluster_command \
       --db-cluster-identifier $CLUSTER_ID --db-instance-class $INSTANCE_CLASS
     

5. Verifikasi bahwa klaster yang Anda buat atau pulihkan memiliki fitur kueri paralel yang tersedia.

   Untuk Aurora MySQL 1.23 dan 2.09 atau versi lebih tinggi: Periksa apakah pengaturan konfigurasi aurora_parallel_query ada. Jika pengaturan ini memiliki nilai 1, kueri paralel siap Anda gunakan. Jika pengaturan ini memiliki nilai 0, atur menjadi 1 sebelum Anda dapat menggunakan kueri paralel. Berapa pun nilainya, klaster ini mampu melakukan kueri paralel.

   mysql> select @@aurora_parallel_query;
   +------------------------+
   | @@aurora_parallel_query|
   +------------------------+
   |                      1 |
   +------------------------+
   

   Sebelum Aurora MySQL 1.23: Periksa apakah pengaturan konfigurasi aurora_pq_supported benar.

   mysql> select @@aurora_pq_supported;
   +-----------------------+
   | @@aurora_pq_supported |
   +-----------------------+
   |                     1 |
   +-----------------------+
   

Untuk memulihkan snapshot ke klaster kueri paralel dengan AWS CLI

1. Periksa versi Aurora MySQL yang mana yang sesuai dengan klaster kueri paralel. Untuk melakukannya, gunakan perintah describe-db-engine-versions dan periksa nilai bidang SupportsParallelQuery. Sebagai contoh, lihat Memeriksa kompatibilitas versi Aurora MySQL untuk kueri paralel. Tentukan versi yang akan digunakan untuk klaster yang dipulihkan. Jika memungkinkan, pilih Aurora MySQL 2.09.0 atau lebih tinggi untuk klaster yang kompatibel dengan MySQL 5.7, atau 1.23.0 atau lebih tinggi untuk klaster yang kompatibel dengan MySQL 5.6.

2. Temukan snapshot klaster yang kompatibel dengan Aurora MySQL.

3. Ikuti prosedur AWS CLI umum dalam Memulihkan dari snapshot klaster DB.

4. Nilai yang digunakan untuk parameter --engine-mode bergantung pada versi mesin yang Anda pilih.

   Untuk Aurora MySQL 1.23 atau lebih tinggi, atau 2.09 atau lebih tinggi, tentukan --engine-mode provisioned. Anda juga dapat menghilangkan parameter --engine-mode, karena provisioned adalah default. Dalam versi ini, Anda dapat mengaktifkan atau menonaktifkan kueri paralel untuk klaster Aurora MySQL Anda, alih-alih membuat klaster yang didedikasikan untuk selalu menggunakan kueri paralel.

   Sebelum Aurora MySQL 1.23, tentukan --engine-mode parallelquery. Parameter --engine-mode berlaku untuk operasi create-db-cluster. Kemudian mode mesin pada klaster digunakan secara otomatis oleh operasi create-db-instance berikutnya.

   aws rds restore-db-cluster-from-snapshot \
     --db-cluster-identifier mynewdbcluster \
     --snapshot-identifier mydbclustersnapshot \
     --engine aurora
     --engine-mode parallelquery
   

5. Verifikasi bahwa klaster yang Anda buat atau pulihkan memiliki fitur kueri paralel yang tersedia. Gunakan prosedur verifikasi yang sama seperti di Membuat klaster kueri paralel menggunakan CLI.

Menghidupkan dan mematikan kueri parallel

Aurora MySQL 1.23 dan 2.09 atau lebih tinggi

Di Aurora MySQL 1.23 dan 2.09 atau lebih tinggi, Anda dapat mengaktifkan dan menonaktifkan kueri parallel secara dinamis pada tingkat global dan sesi untuk instans DB menggunakanaurora_parallel_querypilihan. Anda dapat mengubah pengaturan aurora_parallel_query di grup klaster DB Anda untuk mengaktifkan atau menonaktifkan kueri paralel secara default.

mysql> select @@aurora_parallel_query;
+------------------------+
| @@aurora_parallel_query|
+------------------------+
|                      1 |
+------------------------+

Untuk mengganti parameter aurora_parallel_query pada tingkat sesi, gunakan metode standar untuk mengubah pengaturan konfigurasi klien. Contohnya, Anda dapat melakukannya melalui baris perintah mysql atau dalam aplikasi JDBC atau ODBC. Perintah pada klien MySQL standar adalah set session aurora_parallel_query = {'ON'/'OFF'}. Anda juga dapat menambahkan parameter tingkat sesi ke konfigurasi JDBC atau dalam kode aplikasi Anda untuk mengaktifkan atau menonaktifkan kueri parallel secara dinamis.

Anda dapat secara permanen mengubah pengaturan untuk parameter aurora_parallel_query, baik untuk instans DB tertentu atau untuk seluruh klaster Anda. Jika Anda menetapkan nilai parameter dalam grup parameter DB, nilai tersebut hanya berlaku untuk instans DB tertentu dalam klaster Anda. Jika Anda menetapkan nilai parameter dalam grup parameter klaster DB, semua instans DB di klaster tersebut menerima pengaturan yang sama. Untuk mengganti parameter aurora_parallel_query, gunakan teknik untuk bekerja dengan grup parameter, seperti dijelaskan dalam Bekerja dengan grup parameter. Ikuti langkah-langkah ini:

1. Buat grup parameter klaster kustom (disarankan) atau grup parameter DB kustom.

2. Dalam grup parameter ini, perbarui parallel_query dengan nilai yang Anda inginkan.

3. Bergantung pada apakah Anda membuat grup parameter klaster DB atau grup parameter DB, pasang grup parameter ke klaster Aurora Anda atau ke instans DB spesifik tempat Anda berencana menggunakan fitur kueri paralel.

   Karenaaurora_parallel_queryadalah parameter dinamis, tidak memerlukan cluster restart setelah mengubah pengaturan ini. Namun, koneksi apa pun yang menggunakan kueri parallel sebelum mengaktifkan opsi akan terus melakukannya sampai koneksi ditutup, atau instance di-boot ulang.

Anda dapat memodifikasi parameter query parallel dengan menggunakanModifyDBClusterParameterGroupatauModifyDBParameterGroupOperasi API API atau operasi API API atauAWS Management Console.

Sebelum Aurora MySQL 1.23

Untuk versi yang lebih lama ini, Anda dapat mengaktifkan dan menonaktifkan kueri parallel secara dinamis pada tingkat global dan sesi untuk instans DB menggunakanaurora_pqpilihan. Pada klaster yang fitur kueri parallel tersedia, parameter diaktifkan secara default.

mysql> select @@aurora_pq;
+-------------+
| @@aurora_pq |
+-------------+
|           1 |
+-------------+

Untuk mengganti parameter aurora_pq pada tingkat sesi, contohnya melalui baris perintah mysql atau dalam aplikasi JDBC atau ODBC, gunakan metode standar untuk mengubah pengaturan konfigurasi klien. Misalnya, perintah pada klien MySQL standar adalah set session aurora_pq = {'ON'/'OFF'}. Anda juga dapat menambahkan parameter tingkat sesi ke konfigurasi JDBC atau dalam kode aplikasi Anda untuk mengaktifkan atau menonaktifkan kueri parallel secara dinamis.

Untuk mengganti parameter aurora_pq secara permanen, gunakan teknik untuk bekerja dengan grup parameter, seperti dijelaskan dalam Bekerja dengan grup parameter. Ikuti langkah-langkah ini:

1. Buat grup parameter klaster kustom atau grup parameter instans DB. Kami menyarankan menggunakan grup parameter klaster, sehingga semua instans DB di klaster menerima pengaturan yang sama.

2. Dalam grup parameter ini, perbarui aurora_pq dengan nilai yang Anda inginkan.

3. Kaitkan grup parameter klaster kustom dengan klaster Aurora di mana Anda berencana menggunakan fitur kueri paralel. Atau, untuk grup parameter DB kustom, kaitkan dengan satu atau lebih instans DB dalam klaster.

4. Mulai ulang semua instans DB pada klaster.

Anda dapat memodifikasi parameter query parallel dengan menggunakanModifyDBClusterParameterGroupatauModifyDBParameterGroupOperasi API API atau operasi API API atauAWS Management Console.

Mengaktifkan hash join untuk klaster kueri parallel

Kueri paralel biasanya digunakan untuk jenis kueri sarat sumber daya yang diuntungkan dari pengoptimalan hash join. Oleh karena itu, sangatlah bermanfaat untuk memastikan apakah hash join diaktifkan untuk klaster yang Anda rencanakan akan menggunakan kueri parallel. Untuk informasi tentang cara menggunakan hash join secara efektif, lihatMengoptimalkan besar Aurora MySQL bergabung kueri dengan hash bergabung.

Menghidupkan dan mematikan kueri parallel menggunakan konsol

Anda dapat mengaktifkan atau menonaktifkan kueri parallel di tingkat instans DB atau tingkat klaster DB menggunakan grup parameter.

Untuk mengaktifkan atau menonaktifkan permintaan parallel untuk klaster DB denganAWS Management Console

1. Buat grup parameter khusus, seperti yang dijelaskan di Bekerja dengan grup parameter.

2. Untuk Aurora MySQL 1.23 dan 2.09 atau versi lebih tinggi: Perbaruiaurora_parallel_querykepada1(dihidupkan) atau0 detik(dimatikan). Untuk klaster yang fitur kueri parallel tersedia,aurora_parallel_querydimatikan secara default.

   Untuk Aurora MySQL sebelum 1.23: Perbaruiaurora_pqkepada1(dihidupkan) atau0 detik(dimatikan). Untuk klaster yang fitur kueri parallel tersedia,aurora_pqdiaktifkan secara default.

3. Jika Anda menggunakan grup parameter klaster kustom, lampirkan grup tersebut ke klaster Aurora DB tempat Anda berencana menggunakan fitur kueri paralel. Jika Anda menggunakan grup parameter DVB kustom, lampirkan grup tersebut ke satu atau lebih instans DB dalam klaster. Kami menyarankan menggunakan grup parameter klaster. Melakukan hal tersebut dapat memastikan semua instans DB di klaster memiliki pengaturan yang sama untuk kueri paralel dan fitur terkait seperti hash join.

Menghidupkan dan mematikan kueri parallel menggunakan CLI

Anda dapat memodifikasi parameter kueri paralel dengan menggunakan perintah modify-db-cluster-parameter-group atau modify-db-parameter-group. Pilih perintah yang sesuai, tergantung pada apakah Anda menentukan nilai aurora_parallel_query melalui grup parameter klaster DB atau grup parameter DB.

Mengaktifkan atau menonaktifkan kueri parallel untuk klaster DB dengan CLI

• Ubah parameter kueri paralel menggunakan perintah modify-db-cluster-parameter-group. Gunakan perintah seperti berikut. Ganti dengan nama yang sesuai untuk grup parameter khusus Anda. Ganti ON atau OFF untuk bagian ParameterValue dari opsi --parameters.

  # Aurora MySQL 1.23 or 2.09 and higher:
  $ aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name cluster_param_group_name \
    --parameters ParameterName=aurora_parallel_query,ParameterValue=ON,ApplyMethod=pending-reboot
  {
      "DBClusterParameterGroupName": "cluster_param_group_name"
  }
  
  # Before Aurora MySQL 1.23:
  $ aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name cluster_param_group_name \
    --parameters ParameterName=aurora_pq,ParameterValue=ON,ApplyMethod=pending-reboot
  {
      "DBClusterParameterGroupName": "cluster_param_group_name"
  }
  

Anda juga dapat mengaktifkan atau mematikan kueri parallel di tingkat sesi, contohnya melalui kueri paralel, contohnya melalui kueri paralel.mysqlbaris perintah atau dalam aplikasi JDBC atau ODBC. Untuk melakukannya, gunakan metode standar untuk mengubah pengaturan konfigurasi klien. Misalnya, perintah pada klien MySQL standar adalah set session aurora_parallel_query = {'ON'/'OFF'} untuk Aurora MySQL 1.23 atau 2.09 dan yang lebih tinggi. Sebelum Aurora MySQL 1.23, perintahnya adalah set session aurora_pq = {'ON'/'OFF'}.

Anda juga dapat menambahkan parameter tingkat sesi ke konfigurasi JDBC atau dalam kode aplikasi Anda untuk mengaktifkan atau menonaktifkan kueri parallel secara dinamis.

Pertimbangan peningkatan untuk kueri paralel

Bergantung pada versi asli dan tujuan saat Anda meningkatkan kluster kueri parallel, Anda mungkin menemukan penyempurnaan dalam jenis kueri yang dapat dioptimalkan oleh kueri parallel. Anda mungkin juga menemukan bahwa Anda tidak perlu menentukan parameter mode engine khusus untuk kueri parallel. Bagian berikut menjelaskan pertimbangan saat Anda meningkatkan klaster yang mengaktifkan kueri parallel.

Upgrade cluster query parallel ke Aurora MySQL versi 3

Beberapa pernyataan SQL, klausa, dan tipe data memiliki dukungan kueri parallel baru atau yang lebih baik mulai dari Aurora MySQL versi 3. Saat Anda memutakhirkan dari rilis yang lebih awal dari versi 3, periksa apakah kueri tambahan dapat memperoleh manfaat dari pengoptimalan kueri parallel. Untuk informasi tentang penyempurnaan kueri parallel ini, lihatJenis data kolom,Tabel yang dipartisi, danFungsi agregat, klausul GROUP BY, dan klausul HAVING.

Jika Anda meningkatkan cluster kueri parallel dari Aurora MySQL 2.08 atau yang lebih rendah, pelajari juga tentang perubahan cara mengaktifkan kueri parallel. Untuk melakukannya, bacaMen-upgrade ke Aurora MySQL 1.23 atau 2.09 dan versi lebih tinggi.

Pada Aurora MySQL versi 3, pengoptimalan hash join dinyalakan secara default. Klasteraurora_disable_hash_joinopsi konfigurasi dari versi sebelumnya tidak digunakan.

Men-upgrade ke Aurora MySQL 1.23 atau 2.09 dan versi lebih tinggi

Di Aurora MySQL 1.23 atau 2.09 dan versi lebih tinggi, kueri paralel bekerja untuk klaster yang telah disediakan dan tidak memerlukan parameter mode mesin parallelquery. Dengan demikian, Anda tidak perlu membuat klaster baru atau memulihkan dari snapshot yang sudah ada untuk menggunakan kueri paralel dengan versi ini. Anda dapat menggunakan prosedur peningkatan yang dijelaskan dalam Meningkatkan versi kecil atau level patch dari klaster DB Aurora MySQL untuk meningkatkan klaster Anda ke versi tersebut. Anda dapat meningkatkan klaster yang lebih lama terlepas dari apakah itu berupa klaster kueri paralel atau klaster yang tersedia. Untuk mengurangi jumlah pilihan dalam Versi mesin Anda dapat memilih Tampilkan versi yang mendukung fitur kueri paralel untuk memfilter entri di menu tersebut. Lalu pilih Aurora MySQL 1.23 atau 2.09 dan versi lebih tinggi.

Setelah Anda meningkatkan klaster kueri parallel sebelumnya ke Aurora MySQL 1.23 atau 2.09 atau versi lebih tinggi, Anda mengaktifkan kueri parallel dalam klaster yang ditingkatkan. Kueri paralel dimatikan secara default dalam versi ini, dan prosedur untuk mengaktifkannya berbeda. Pengoptimalan hash join juga dimatikan secara default dan harus diaktifkan secara terpisah. Maka, pastikan Anda mengaktifkan pengaturan ini lagi setelah peningkatan. Untuk petunjuk tentang melakukannya, lihat Menghidupkan dan mematikan kueri parallel dan Mengaktifkan hash join untuk klaster kueri parallel.

Secara khusus, Anda mengaktifkan query parallel dengan menggunakan parameter konfigurasiaurora_parallel_query=ONdanaurora_disable_hash_join=OFFbukannyaaurora_pq_supporteddanaurora_pq. Parameter aurora_pq_supported dan aurora_pq diusangkan dalam versi Aurora MySQL yang lebih baru.

Dalam klaster yang ditingkatkan, atribut EngineMode memiliki nilai provisioned sebagai ganti parallelquery. Untuk memeriksa apakah kueri paralel tersedia untuk versi mesin tertentu, sekarang Anda memeriksa nilai bidang SupportsParallelQuery di output perintah describe-db-engine-versions AWS CLI. Di versi Aurora MySQL versi sebelumnya, Anda memeriksa keberadaan parallelquery dalam daftar SupportedEngineModes.

Setelah meningkatkan ke Aurora MySQL 1.23 atau 2.09 dan versi lebih tinggi, Anda dapat memanfaatkan fitur-fitur berikut. Fitur ini tidak tersedia untuk klaster kueri paralel yang menjalankan Aurora MySQL versi lama.

• Wawasan Kinerja. Untuk informasi selengkapnya, lihat Memantau beban DB dengan Performance InsightsAmazon Aurora.

• Pelacakan Mundur. Untuk informasi selengkapnya, lihat Pelacakan mundur klaster DB Aurora.

• Berhenti dan memulai klaster. Untuk informasi selengkapnya, lihat Menghentikan dan memulai klaster DB Amazon Aurora.

Penyempurnaan kinerja untuk kueri paralel

Untuk mengelola kinerja beban kerja dengan kueri paralel, pastikan kueri paralel digunakan untuk kueri di mana pengoptimalan ini paling membantu.

Untuk melakukannya, Anda dapat melakukan hal berikut:

• Pastikan bahwa tabel terbesar Anda kompatibel dengan kueri paralel. Anda mungkin mengubah properti tabel atau membuat ulang beberapa tabel sehingga kueri untuk tabel tersebut dapat memanfaatkan pengoptimalan kueri paralel. Untuk mempelajari caranya, lihat Membuat objek skema untuk memanfaatkan kueri paralel.

• Pantau kueri mana yang menggunakan kueri paralel. Untuk mempelajari caranya, lihat Memantau kueri paralel.

• Verifikasi bahwa kueri paralel digunakan untuk kueri sarat data dan berlangsung lama, dan dengan tingkat keserentakan yang tepat untuk beban kerja Anda. Untuk mempelajari caranya, lihat Memverifikasi pernyataan mana yang menggunakan kueri paralel.

• Sesuaikan kode SQL Anda untuk mengaktifkan kueri parallel agar diterapkan pada kueri yang Anda harapkan. Untuk mempelajari caranya, lihat Cara kerja kueri paralel dengan konstruksi SQL.

Membuat objek skema untuk memanfaatkan kueri paralel

Sebelum Anda membuat atau memodifikasi tabel yang akan Anda gunakan untuk kueri paralel, pastikan untuk memahami persyaratan yang dijelaskan dalam Prasyarat dan Keterbatasan:.

Karena kueri paralel memerlukan tabel untuk menggunakan pengaturan ROW_FORMAT=Compact atau ROW_FORMAT=Dynamic, periksa pengaturan konfigurasi Aurora Anda untuk setiap perubahan pada opsi konfigurasi INNODB_FILE_FORMAT. Keluarkan pernyataan SHOW TABLE STATUS untuk mengonfirmasi format baris untuk semua tabel dalam database.

Sebelum mengubah skema Anda untuk mengaktifkan kueri parallel agar dapat bekerja dengan lebih banyak tabel, pastikan untuk melakukan pengujian. Pengujian Anda harus mengonfirmasi apakah kueri paralel menghasilkan peningkatan kinerja bersih untuk tabel tersebut. Selain itu, pastikan bahwa persyaratan skema untuk kueri paralel kompatibel sesuai dengan sasaran Anda.

Sebagai contoh, sebelum beralih dari ROW_FORMAT=Compressed menjadi ROW_FORMAT=Compact atau ROW_FORMAT=Dynamic, uji kinerja beban kerja untuk tabel asal dan baru. Selain itu, pertimbangkan potensi efek lainnya seperti peningkatan volume data.

Memverifikasi pernyataan mana yang menggunakan kueri paralel

Dalam operasi biasa, Anda tidak perlu melakukan tindakan khusus apa pun untuk memanfaatkan kueri paralel. Setelah kueri memenuhi persyaratan penting untuk kueri paralel, pengoptimal kueri secara otomatis memutuskan apakah akan menggunakan kueri paralel untuk setiap kueri tertentu.

Jika menjalankan percobaan di lingkungan pengembangan atau pengujian, Anda mungkin menemukan bahwa kueri paralel tidak digunakan karena tabel Anda terlalu kecil dalam jumlah baris atau volume data keseluruhan. Data untuk tabel mungkin juga sepenuhnya berada di dalam buffer pool, terutama untuk tabel yang baru Anda buat untuk melakukan percobaan.

Saat Anda memantau atau menyesuaikan kinerja klaster, pastikan untuk memutuskan apakah kueri paralel digunakan dalam konteks yang sesuai. Anda dapat menyesuaikan skema basis data, pengaturan, kueri SQL, atau bahkan klaster topologi dan pengaturan koneksi aplikasi untuk memanfaatkan fitur ini.

Untuk memeriksa apakah suatu kueri menggunakan kueri paralel, periksa rencana kueri (juga dikenal sebagai "rencana menjelaskan") dengan menjalankan pernyataan EXPLAIN. Sebagai contoh bagaimana pernyataan, klausul, dan ekspresi SQL memengaruhi output EXPLAIN untuk kueri paralel, lihat Cara kerja kueri paralel dengan konstruksi SQL.

Contoh berikut menunjukkan perbedaan antara rencana kueri tradisional dan rencana kueri paralel. Rencana menjelaskan ini adalah dari Query 3 dari tolok ukur TPC-H. Banyak sampel kueri di seluruh bagian ini menggunakan tabel dari set data TPC-H. Anda dapat memperoleh definisi tabel, kueri, dan program dbgen yang menghasilkan data sampel dari situs web TPC-h.

EXPLAIN SELECT l_orderkey,
  sum(l_extendedprice * (1 - l_discount)) AS revenue,
  o_orderdate,
  o_shippriority
FROM customer,
  orders,
  lineitem
WHERE c_mktsegment = 'AUTOMOBILE'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < date '1995-03-13'
AND l_shipdate > date '1995-03-13'
GROUP BY l_orderkey,
  o_orderdate,
  o_shippriority
ORDER BY revenue DESC,
  o_orderdate LIMIT 10;

Secara default, kueri tersebut mungkin memiliki rencana seperti berikut. Jika Anda tidak melihat hash join digunakan dalam rencana kueri, pastikan pengoptimalan diaktifkan terlebih dahulu.

+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
| id | select_type | table    | partitions | type | possible_keys | key  | key_len | ref  | rows     | filtered | Extra                                              |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+
|  1 | SIMPLE      | customer | NULL       | ALL  | NULL          | NULL | NULL    | NULL |  1480234 |    10.00 | Using where; Using temporary; Using filesort       |
|  1 | SIMPLE      | orders   | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 14875240 |     3.33 | Using where; Using join buffer (Block Nested Loop) |
|  1 | SIMPLE      | lineitem | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 59270573 |     3.33 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+

Anda dapat mengaktifkan hash join di tingkat sesi dengan mengeluarkan pernyataan berikut. Kemudian, coba pernyataan EXPLAIN lagi.

# For Aurora MySQL version 3:
SET optimizer_switch='block_nested_loop=on';

# For Aurora MySQL version 2.09 and higher:
SET optimizer_switch='hash_join=on';

Untuk informasi tentang cara menggunakan hash join secara efektif, lihatMengoptimalkan besar Aurora MySQL bergabung kueri dengan hash bergabung.

Dengan hash join aktif tetapi kueri parallel dinonaktifkan, kueri mungkin memiliki rencana seperti berikut, yang menggunakan hash join tetapi bukan kueri parallel.

+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
| id | select_type | table    |...| rows      | Extra                                                           |
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
|  1 | SIMPLE      | customer |...|   5798330 | Using where; Using index; Using temporary; Using filesort       |
|  1 | SIMPLE      | orders   |...| 154545408 | Using where; Using join buffer (Hash Join Outer table orders)   |
|  1 | SIMPLE      | lineitem |...| 606119300 | Using where; Using join buffer (Hash Join Outer table lineitem) |
+----+-------------+----------+...+-----------+-----------------------------------------------------------------+

Setelah kueri parallel diaktifkan, dua langkah dalam rencana kueri ini dapat menggunakan pengoptimalan kueri parallel, seperti ditunjukkan di bawahExtrakolom dalam kolomEXPLAINoutput. Pemrosesan sarat I/O dan CPU untuk langkah-langkah tersebut diturunkan ke lapisan penyimpanan.

+----+...+--------------------------------------------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                                                          |
+----+...+--------------------------------------------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using index; Using temporary; Using filesort                                                                      |
|  1 |...| Using where; Using join buffer (Hash Join Outer table orders); Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra)   |
|  1 |...| Using where; Using join buffer (Hash Join Outer table lineitem); Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra) |
+----+...+--------------------------------------------------------------------------------------------------------------------------------+

Untuk informasi tentang cara menginterpretasi output EXPLAIN untuk kueri paralel dan bagian pernyataan SQL yang dapat diterapkan oleh kueri paralel, lihat Cara kerja kueri paralel dengan konstruksi SQL.

Contoh output berikut menunjukkan hasil dari menjalankan kueri sebelumnya pada instans db.r4.2xlarge dengan IT buffer pool dingin. Kueri berjalan jauh lebih cepat saat menggunakan kueri paralel.

Karena waktu tergantung pada banyak faktor lingkungan, hasil Anda mungkin berbeda. Selalu lakukan uji kinerja Anda sendiri untuk mengonfirmasi temuan dengan lingkungan dan beban kerja Anda sendiri, dan sebagainya.

-- Without parallel query
+------------+-------------+-------------+----------------+
| l_orderkey | revenue     | o_orderdate | o_shippriority |
+------------+-------------+-------------+----------------+
|   92511430 | 514726.4896 | 1995-03-06  |              0 |
.
.
|   28840519 | 454748.2485 | 1995-03-08  |              0 |
+------------+-------------+-------------+----------------+
10 rows in set (24 min 49.99 sec)

-- With parallel query
+------------+-------------+-------------+----------------+
| l_orderkey | revenue     | o_orderdate | o_shippriority |
+------------+-------------+-------------+----------------+
|   92511430 | 514726.4896 | 1995-03-06  |              0 |
.
.
|   28840519 | 454748.2485 | 1995-03-08  |              0 |
+------------+-------------+-------------+----------------+
10 rows in set (1 min 49.91 sec)

Banyak kueri sampel di seluruh bagian ini menggunakan tabel dari set data TPC-H ini, khususnya tabel PART, yang memiliki 20 juta baris dan definisi berikut.

+---------------+---------------+------+-----+---------+-------+
| Field         | Type          | Null | Key | Default | Extra |
+---------------+---------------+------+-----+---------+-------+
| p_partkey     | int(11)       | NO   | PRI | NULL    |       |
| p_name        | varchar(55)   | NO   |     | NULL    |       |
| p_mfgr        | char(25)      | NO   |     | NULL    |       |
| p_brand       | char(10)      | NO   |     | NULL    |       |
| p_type        | varchar(25)   | NO   |     | NULL    |       |
| p_size        | int(11)       | NO   |     | NULL    |       |
| p_container   | char(10)      | NO   |     | NULL    |       |
| p_retailprice | decimal(15,2) | NO   |     | NULL    |       |
| p_comment     | varchar(23)   | NO   |     | NULL    |       |
+---------------+---------------+------+-----+---------+-------+

Lakukan eksperimen dengan beban kerja Anda untuk mengetahui apakah pernyataan SQL individual dapat memanfaatkan kueri paralel. Lalu gunakan teknik pemantauan berikut untuk membantu memverifikasi frekuensi penggunaan kueri paralel dalam beban kerja nyata dari waktu ke waktu. Untuk beban kerja nyata, faktor tambahan seperti batas keserentakan berlaku.

Memantau kueri paralel

Jika klaster Aurora MySQL Anda menggunakan kueri parallel, Anda mungkin melihat peningkatanVolumeReadIOPSnilai. Kueri paralel tidak menggunakan buffer pool. Dengan demikian, meskipun kueri cepat, pemrosesan yang dioptimalkan ini dapat menghasilkan peningkatan operasi baca dan biaya terkait.

Selain Amazon CloudWatch metrik yang dijelaskan dalamMelihat metrik di konsol Amazon RDS, Aurora menyediakan variabel status global lainnya. Anda dapat menggunakan variabel status global ini untuk membantu memantau eksekusi kueri paralel. Variabel tersebut dapat memberi Anda wawasan tentang alasan pengoptimal dapat menggunakan atau tidak menggunakan kueri paralel dalam situasi tertentu. Untuk mengakses variabel ini, Anda dapat menggunakan perintah SHOW GLOBAL STATUS. Anda juga dapat menemukan variabel ini tercantum sebagai berikut.

Sesi kueri parallel belum tentu a one-to-one pemetaan dengan query yang dilakukan oleh database. Contohnya, anggaplah bahwa rencana kueri Anda memiliki dua langkah yang menggunakan kueri paralel. Dalam hal ini, kueri tersebut mencakup dua sesi paralel dan penghitung untuk permintaan yang telah diupayakan dan permintaan yang berhasil ditambah sebanyak dua.

Saat Anda bereksperimen dengan kueri paralel dengan mengeluarkan pernyataan EXPLAIN, bersiaplah untuk melihat kenaikan di penghitung yang ditetapkan sebagai "tidak dipilih" meskipun kueri tersebut sebenarnya tidak berjalan. Saat bekerja dengan kueri paralel dalam produksi, Anda dapat memeriksa apakah penghitung yang "tidak dipilih" meningkat lebih cepat dari yang Anda perkirakan. Pada titik ini, Anda dapat menyesuaikan sehingga kueri paralel berjalan untuk kueri yang Anda harapkan. Untuk melakukannya, Anda dapat mengubah pengaturan klaster, campuran kueri, instans DB di mana kueri parallel diaktifkan, dan sebagainya.

Penghitung ini dilacak di tingkat instans DB. Saat terhubung ke titik akhir yang berbeda, Anda mungkin melihat metrik yang berbeda karena setiap instans DB menjalankan serangkaian kueri paralelnya sendiri. Anda mungkin juga melihat metrik yang berbeda saat titik akhir pembaca terhubung ke instans DB yang berbeda untuk setiap sesi.

Cara kerja kueri paralel dengan konstruksi SQL

Pada bagian berikut, Anda dapat menemukan perincian lebih lanjut tentang alasan laporan SQL tertentu menggunakan atau tidak menggunakan kueri paralel. Bagian ini juga memperinci cara fitur Aurora MySQL berinteraksi dengan kueri paralel. Informasi ini dapat membantu Anda mendiagnosis masalah kinerja untuk klaster yang menggunakan kueri paralel atau memahami cara kueri paralel berlaku untuk beban kerja tertentu Anda.

Keputusan untuk menggunakan kueri paralel bergantung pada banyak faktor yang terjadi pada saat pernyataan itu berjalan. Dengan demikian, kueri paralel dapat digunakan untuk kueri tertentu selalu, tidak pernah, atau hanya dalam kondisi tertentu.

Saat melihat contoh ini di HTML, Anda dapat menggunakan Salin widget di sudut kanan atas setiap daftar kode guna menyalin kode SQL untuk mencoba sendiri. Menggunakan widget Salin akan terhindar dari menyalin karakter tambahan di sekitar prompt mysql> dan baris lanjutan ->.

Topik

• Pernyataan EXPLAIN
• Klausul WHERE
• Bahasa definisi data (DDL)
• Jenis data kolom
• Tabel yang dipartisi
• Fungsi agregat, klausul GROUP BY, dan klausul HAVING
• Panggilan fungsi dalam klausul WHERE
• Klausul LIMIT
• Operator perbandingan
• Bergabung
• Subkueri
• UNION
• Tampilan
• Pernyataan bahasa manipulasi data (DML)
• Transaksi dan penguncian
• Indeks pohon B
• Indeks pencarian teks penuh (FTS)
• Kolom virtual
• Mekanisme caching bawaan
• Tabel sementara MyISAM

Pernyataan EXPLAIN

Seperti yang ditunjukkan dalam contoh di seluruh bagian ini, pernyataan EXPLAIN menunjukkan apakah setiap tahap kueri saat ini memenuhi syarat untuk kueri paralel. Pernyataan itu juga menunjukkan aspek mana dari kueri yang dapat diturunkan ke lapisan penyimpanan. Berikut ini adalah item terpenting dalam rencana kueri:

• Nilai selain NULL untuk kolom key menunjukkan bahwa kueri dapat dilakukan secara efisien menggunakan pencarian indeks, dan kueri paralel tidak memungkinkan.

• Nilai kecil untuk kolom rows (nilai bukan dalam jutaan) menunjukkan bahwa kueri tersebut tidak mengakses cukup data untuk membuat kueri paralel yang bermanfaat. Ini berarti kueri paralel tidak memungkinkan.

• Kolom Extra menunjukkan jika kueri paralel yang diharapkan akan digunakan. Output ini terlihat seperti contoh berikut.

  Using parallel query (A columns, B filters, C exprs; D extra)
  

  Angka columns menunjukkan jumlah kolom yang dimaksud dalam blok kueri.

  Angka filters menunjukkan jumlah predikat WHERE yang menunjukkan perbandingan sederhana antara nilai kolom dan konstanta. Perbandingannya dapat berupa kesetaraan, ketidaksetaraan, atau rentang. Aurora dapat memaralelkan jenis predikat ini dengan sangat efektif.

  Angka exprs menunjukkan jumlah ekspresi seperti panggilan fungsi, operator, atau ekspresi lainnya yang juga dapat diparalelkan, meskipun tidak sama efektifnya dengan ketentuan filter.

  Angka extra menunjukkan jumlah ekspresi yang tidak dapat diturunkan dan dilakukan oleh simpul kepala.

Contohnya, pertimbangkan output EXPLAIN berikut ini.

mysql> explain select p_name, p_mfgr from part
    -> where p_brand is not null
    -> and upper(p_type) is not null
    -> and round(p_retailprice) is not null;
+----+-------------+-------+...+----------+----------------------------------------------------------------------------+
| id | select_type | table |...| rows     | Extra                                                                      |
+----+-------------+-------+...+----------+----------------------------------------------------------------------------+
|  1 | SIMPLE      | part  |...| 20427936 | Using where; Using parallel query (5 columns, 1 filters, 2 exprs; 0 extra) |
+----+-------------+-------+...+----------+----------------------------------------------------------------------------+

Informasi dari kolom Extra menunjukkan bahwa lima kolom diekstraksi dari setiap baris untuk mengevaluasi ketentuan kueri dan menyusun set hasil. Satu predikat WHERE mencakup sebuah filter, yaitu, kolom yang langsung diuji dalam klausul WHERE. Dua klausul WHERE memerlukan evaluasi ekspresi yang lebih rumit, dalam hal ini mencakup panggilan fungsi. Bidang 0 extra mengonfirmasi bahwa semua operasi dalam klausul WHERE diturunkan ke lapisan penyimpanan sebagai bagian dari pemrosesan kueri paralel.

Dalam kasus di mana kueri paralel tidak dipilih, Anda biasanya dapat menyimpulkan alasan dari output kolom lain EXPLAIN. Contohnya, nilai rows mungkin terlalu kecil, atau kolom possible_keys mungkin menunjukkan bahwa kueri dapat menggunakan pencarian indeks alih-alih pemindaian sarat data. Contoh berikut menunjukkan suatu kueri di mana pengoptimal dapat memperkirakan bahwa kueri tersebut hanya akan memindai sejumlah kecil baris. Hal itu dilakukan berdasarkan karakteristik kunci utama. Dalam hal ini, kueri paralel tidak diperlukan.

mysql> explain select count(*) from part where p_partkey between 1 and 100;
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra                    |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+
|  1 | SIMPLE      | part  | range | PRIMARY       | PRIMARY | 4       | NULL |   99 | Using where; Using index |
+----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+

Output yang menunjukkan apakah kueri paralel akan digunakan telah mempertimbangkan semua faktor yang tersedia saat pernyataan EXPLAIN dijalankan. Pengoptimal mungkin mengambil pilihan lain saat kueri tersebut benar-benar berjalan, jika situasi diubah pada saat itu. Contohnya, EXPLAIN dapat melaporkan bahwa suatu pernyataan akan menggunakan kueri paralel. Namun saat kueri benar-benar berjalan kemudian, kueri tersebut mungkin tidak menggunakan kueri paralel berdasarkan kondisi pada saat itu. Kondisi tersebut dapat mencakup beberapa kueri paralel lainnya yang berjalan secara serentak. Kondisi lainnya juga dapat mencakup baris yang dihapus dari tabel, indeks baru yang dibuat, terlalu banyak waktu yang terlewati dalam transaksi terbuka, dan sebagainya.

Klausul WHERE

Agar menggunakan pengoptimalan kueri paralel, suatu kueri harus termasuk klausul WHERE.

Pengoptimalan kueri paralel mempercepat berbagai jenis ekspresi yang digunakan dalam klausul WHERE:

• Perbandingan sederhana antara nilai kolom dengan konstanta, yang disebut filter. Perbandingan ini sangat diuntungkan karena diturunkan ke lapisan penyimpanan. Jumlah ekspresi filter dalam kueri dilaporkan dalam output EXPLAIN.

• Jenis ekspresi lain dalam klausul WHERE juga diturunkan ke lapisan penyimpanan jika memungkinkan. Jumlah ekspresi tersebut dalam kueri dilaporkan dalam output EXPLAIN. Ekspresi ini dapat berupa panggilan fungsi, operator LIKE, ekspresi CASE, dan sebagainya.

• Fungsi dan operator tertentu saat ini tidak diturunkan oleh kueri paralel. Jumlah ekspresi tersebut dalam kueri dilaporkan sebagai penghitung extra dalam output EXPLAIN. Sisa kueri tersebut masih dapat menggunakan kueri paralel.

• Meskipun ekspresi dalam daftar pilihan tidak diturunkan, kueri yang berisi fungsi tersebut masih dapat diuntungkan dari pengurangan lalu lintas jaringan untuk hasil perantara dari kueri paralel. Contohnya, kueri yang memanggil fungsi agregat dalam daftar pilihan dapat diuntungkan dari kueri paralel, meskipun fungsi agregasi tidak diturunkan.

Contohnya, kueri berikut ini melakukan pemindaian tabel lengkap dan memproses semua nilai untuk kolom P_BRAND. Akan tetapi, kueri tersebut tidak menggunakan kueri paralel karena tidak mencakup klausul WHERE apa pun.

mysql> explain select count(*), p_brand from part group by p_brand;
+----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows     | Extra                           |
+----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+
|  1 | SIMPLE      | part  | ALL  | NULL          | NULL | NULL    | NULL | 20427936 | Using temporary; Using filesort |
+----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+

Sebaliknya, kueri berikut mencakup predikat WHERE yang memfilter hasil, sehingga kueri paralel dapat diterapkan:

mysql> explain select count(*), p_brand from part where p_name is not null
    ->   and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000
    -> group by p_brand;
+----+...+----------+-------------------------------------------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                                                       |
+----+...+----------+-------------------------------------------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using temporary; Using filesort; Using parallel query (5 columns, 1 filters, 2 exprs; 0 extra) |
+----+...+----------+-------------------------------------------------------------------------------------------------------------+

Jika pengoptimal memperkirakan bahwa jumlah baris yang dikembalikan untuk suatu blok kueri adalah kecil, kueri paralel tidak digunakan untuk blok kueri tersebut. Contoh berikut menunjukkan kasus di mana operator lebih-besar-dari pada kolom kunci utama berlaku untuk jutaan baris, yang menyebabkan kueri paralel digunakan. Uji kurang-dari yang berkebalikan diperkirakan berlaku hanya pada beberapa baris dan tidak menggunakan kueri paralel.

mysql> explain select count(*) from part where p_partkey > 10;
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------+----------------------------------------------------------------------------+

mysql> explain select count(*) from part where p_partkey < 10;
+----+...+------+--------------------------+
| id |...| rows | Extra                    |
+----+...+------+--------------------------+
|  1 |...|    9 | Using where; Using index |
+----+...+------+--------------------------+

Bahasa definisi data (DDL)

Sebelum Aurora MySQL versi 3, kueri parallel hanya tersedia untuk tabel di mana tidak ada operasi bahasa definisi data (DDL) yang tertunda. Dalam Aurora MySQL versi 3, Anda dapat menggunakan query parallel di atas meja pada saat yang sama sebagai operasi DDL instan. DDL instan di Aurora MySQL versi 3 menggantikan fitur DDL cepat di Aurora MySQL versi 1 dan 2. Untuk informasi tentang DDL, lihatInstan DDL (Aurora MySQL versi 3).

Jenis data kolom

Dalam Aurora MySQL versi 3, query parallel dapat bekerja dengan tabel yang berisi kolom dengan tipe dataTEXT,BLOB,JSON, danGEOMETRY. Hal ini juga dapat bekerja denganVARCHARdanCHARkolom dengan panjang dideklarasikan maksimum lebih dari 768 byte. Jika kueri Anda mengacu pada kolom yang berisi tipe objek besar seperti itu, pekerjaan tambahan untuk mengambilnya menambahkan beberapa overhead ke pemrosesan kueri. Dalam hal ini, periksa apakah query dapat menghilangkan referensi ke kolom tersebut. Jika tidak, jalankan tolok ukur untuk mengonfirmasi apakah kueri tersebut lebih cepat dengan permintaan parallel dihidupkan atau dimatikan.

Sebelum Aurora MySQL versi 3, query parallel memiliki batasan ini untuk jenis objek besar:

Dalam versi sebelumnya,TEXT,BLOB,JSON, danGEOMETRYTipe data tidak didukung dengan kueri parallel. Kueri yang mengacu pada kolom apa pun dari jenis ini tidak dapat menggunakan kueri paralel.

Dalam versi sebelumnya, kolom variabel-panjang (VARCHARdanCHARjenis data) kompatibel dengan kueri parallel hingga panjang maksimum maksimum yang dinyatakan 768 byte. Suatu kueri yang mengacu pada kolom apa pun dari jenis yang dinyatakan dengan panjang maksimum yang lebih panjang tidak dapat menggunakan kueri paralel. Untuk kolom yang menggunakan set karakter multibyte, batas byte mempertimbangkan jumlah maksimum byte dalam set karakter. Contohnya, untuk set karakter utf8mb4 (yang memiliki panjang karakter maksimum 4 byte), kolom VARCHAR(192) kompatibel dengan kueri paralel tetapi kolom VARCHAR(193) tidak.

Tabel yang dipartisi

Anda dapat menggunakan tabel yang dipartisi dengan kueri parallel di Aurora MySQL versi 3. Karena tabel dipartisi diwakili secara internal sebagai beberapa tabel yang lebih kecil, query yang menggunakan query parallel pada tabel nonpartisi mungkin tidak menggunakan query parallel pada tabel dipartisi identik. Aurora MySQL mempertimbangkan apakah setiap partisi cukup besar untuk memenuhi syarat untuk optimasi kueri parallel, alih-alih mengevaluasi ukuran seluruh tabel. Periksa apakahAurora_pq_request_not_chosen_small_tablevariabel status bertambah jika query pada tabel dipartisi tidak menggunakan query parallel ketika Anda mengharapkannya.

Misalnya, pertimbangkan satu tabel yang dipartisi denganPARTITION BY HASH (column) PARTITIONS 2dan meja lain dipartisi denganPARTITION BY HASH (column) PARTITIONS 10. Dalam tabel dengan dua partisi, partisi lima kali lebih besar dari tabel dengan sepuluh partisi. Dengan demikian, query parallel lebih mungkin untuk digunakan untuk query terhadap tabel dengan partisi yang lebih sedikit. Pada contoh berikut, tabel berikut iniPART_BIG_PARTITIONSmemiliki dua partisi danPART_SMALL_PARTITIONSmemiliki sepuluh partisi. Dengan data yang identik, query parallel lebih mungkin untuk digunakan untuk tabel dengan partisi besar lebih sedikit.

mysql> explain select count(*), p_brand from part_big_partitions where p_name is not null
    ->   and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000 group by p_brand;
+----+-------------+---------------------+------------+-------------------------------------------------------------------------------------------------------------------+
| id | select_type | table               | partitions | Extra                                                                                                             |
+----+-------------+---------------------+------------+-------------------------------------------------------------------------------------------------------------------+
|  1 | SIMPLE      | part_big_partitions | p0,p1      | Using where; Using temporary; Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra; 1 group-bys, 1 aggrs) |
+----+-------------+---------------------+------------+-------------------------------------------------------------------------------------------------------------------+

mysql> explain select count(*), p_brand from part_small_partitions where p_name is not null
    ->   and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000 group by p_brand;
+----+-------------+-----------------------+-------------------------------+------------------------------+
| id | select_type | table                 | partitions                    | Extra                        |
+----+-------------+-----------------------+-------------------------------+------------------------------+
|  1 | SIMPLE      | part_small_partitions | p0,p1,p2,p3,p4,p5,p6,p7,p8,p9 | Using where; Using temporary |
+----+-------------+-----------------------+-------------------------------+------------------------------+

Fungsi agregat, klausul GROUP BY, dan klausul HAVING

Kueri yang mencakup fungsi agregat sering kali merupakan kandidat yang baik untuk kueri paralel, karena kueri tersebut memindai baris dalam jumlah besar dalam tabel besar.

Di Aurora MySQL 3, permintaan parallel dapat mengoptimalkan panggilan fungsi agregat dalam daftar pilih danHAVINGklausul.

Sebelum Aurora MySQL 3, panggilan fungsi agregat dalam daftar pilihan atauHAVINGklausul tidak diturunkan ke lapisan penyimpanan. Akan tetapi, kueri paralel tetap dapat meningkatkan kinerja kueri dengan fungsi agregat tersebut. Hal itu dilakukan pertama-tama dengan mengekstraksi nilai kolom dari halaman data mentah secara paralel pada lapisan penyimpanan. Kueri paralel tersebut kemudian mengirim kembali nilai itu ke simpul kepala dalam format urutan yang padat, bukan sebagai keseluruhan halaman data. Seperti biasa, kueri memerlukan setidaknya satu predikat WHERE agar kueri paralel dapat diaktifkan.

Contoh sederhana berikut mengilustrasikan jenis kueri agregat yang dapat diuntungkan dari kueri paralel. Hal tersebut dilakukan dengan mengembalikan hasil menengah dalam bentuk ringkas ke simpul kepala, memfilter baris yang tidak cocok dari hasil menengah, atau keduanya.

mysql> explain select sql_no_cache count(distinct p_brand) from part where p_mfgr = 'Manufacturer#5';
+----+...+----------------------------------------------------------------------------+
| id |...| Extra                                                                      |
+----+...+----------------------------------------------------------------------------+
|  1 |...| Using where; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------------------------------------------------------------------------+

mysql> explain select sql_no_cache p_mfgr from part where p_retailprice > 1000 group by p_mfgr having count(*) > 100;
+----+...+-------------------------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                                       |
+----+...+-------------------------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using temporary; Using filesort; Using parallel query (3 columns, 0 filters, 1 exprs; 0 extra) |
+----+...+-------------------------------------------------------------------------------------------------------------+

Panggilan fungsi dalam klausul WHERE

Aurora dapat menerapkan pengoptimalan kueri paralel pada panggilan ke sebagian besar fungsi bawaan dalam klausul WHERE. Paralelisasi panggilan fungsi ini membongkar beberapa pekerjaan CPU dari simpul kepala. Mengevaluasi fungsi predikat secara paralel selama tahap kueri terawal akan membantu Aurora meminimalkan jumlah data yang dikirim dan diproses selama tahap berikutnya.

Saat ini, paralelisasi tidak berlaku untuk panggilan fungsi dalam daftar pilihan. Fungsi-fungsi tersebut dievaluasi oleh simpul kepala, bahkan jika panggilan fungsi yang identik muncul dalam klausul WHERE. Nilai asli dari kolom yang relevan disertakan dalam urutan yang dikirim dari simpul penyimpanan kembali ke simpul kepala. Simpul kepala melakukan transformasi apa pun seperti UPPER, CONCATENATE, dan seterusnya untuk menghasilkan nilai akhir untuk set hasil.

Dalam contoh berikut, kueri paralel memaralelkan panggilan dengan LOWER karena muncul di klausul WHERE. Kueri paralel tidak memengaruhi panggilan menjadi SUBSTR dan UPPER karena muncul dalam daftar pilihan.

mysql> explain select sql_no_cache distinct substr(upper(p_name),1,5) from part
    -> where lower(p_name) like '%cornflower%' or lower(p_name) like '%goldenrod%';
+----+...+---------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                       |
+----+...+---------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using temporary; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
+----+...+---------------------------------------------------------------------------------------------+

Pertimbangan yang sama berlaku untuk ekspresi lain, seperti ekspresi CASE atau operator LIKE. Contohnya, contoh berikut menunjukkan bahwa kueri paralel mengevaluasi ekspresi CASE dan LIKE di klausul WHERE.

mysql> explain select p_mfgr, p_retailprice from part
    -> where p_retailprice > case p_mfgr
    ->   when 'Manufacturer#1' then 1000
    ->   when 'Manufacturer#2' then 1200
    ->   else 950
    -> end
    -> and p_name like '%vanilla%'
    -> group by p_retailprice;
+----+...+-------------------------------------------------------------------------------------------------------------+
| id |...| Extra                                                                                                       |
+----+...+-------------------------------------------------------------------------------------------------------------+
|  1 |...| Using where; Using temporary; Using filesort; Using parallel query (4 columns, 0 filters, 2 exprs; 0 extra) |
+----+...+-------------------------------------------------------------------------------------------------------------+

Klausul LIMIT

Saat ini, kueri paralel tidak digunakan untuk blok kueri yang mencakup klausul LIMIT. Kueri paralel masih dapat digunakan untuk fase kueri sebelumnya dengan GROUP oleh, ORDER BY, atau gabungan.

Operator perbandingan

Pengoptimal memperkirakan jumlah baris yang harus dipindai untuk mengevaluasi operator perbandingan, dan menentukan apakah akan menggunakan kueri paralel berdasarkan estimasi tersebut.

Contoh pertama berikut ini menunjukkan bahwa perbandingan setara terhadap kolom kunci utama dapat dilakukan secara efisien tanpa kueri paralel. Contoh kedua berikut menunjukkan bahwa perbandingan yang serupa terhadap kolom yang tidak diindeks memerlukan pemindaian jutaan baris, sehingga dapat diuntungkan dari kueri paralel.

mysql> explain select * from part where p_partkey = 10;
+----+...+------+-------+
| id |...| rows | Extra |
+----+...+------+-------+
|  1 |...|    1 | NULL  |
+----+...+------+-------+

mysql> explain select * from part where p_type = 'LARGE BRUSHED BRASS';
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (9 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------+----------------------------------------------------------------------------+

Pertimbangan yang sama berlaku untuk pengujian yang tidak sama dan untuk perbandingan rentang seperti kurang dari, lebih besar dari atau sama dengan, atau BETWEEN. Pengoptimal memperkirakan jumlah baris yang akan dipindai, dan menentukan apakah kueri paralel bermanfaat berdasarkan volume keseluruhan I/O.

Bergabung

Kueri gabungan dengan tabel besar biasanya mencakup operasi sarat data yang diuntungkan dari pengoptimalan kueri paralel. Perbandingan nilai kolom di antara beberapa tabel (yaitu, predikat gabungan itu sendiri) saat ini tidak diparalelkan. Namun, kueri paralel dapat menurunkan beberapa pemrosesan internal untuk fase penggabungan lainnya, seperti membangun filter Bloom selama hash join. Kueri paralel dapat diterapkan pada kueri gabungan tanpa klausul WHERE. Oleh karena itu, kueri gabungan adalah pengecualian untuk aturan bahwa klausul WHERE diperlukan untuk menggunakan kueri paralel.

Setiap fase pemrosesan gabungan dievaluasi untuk memeriksa apakah fase tersebut memenuhi syarat untuk kueri paralel. Jika lebih dari satu fase dapat menggunakan kueri paralel, fase-fase ini dilakukan secara berurutan. Dengan demikian, setiap kueri gabungan dihitung sebagai satu sesi kueri paralel dalam hal batas keserentakan.

Contohnya, saat kueri gabungan mencakup predikat WHERE untuk memfilter baris dari salah satu tabel yang digabungkan, opsi pemfilteran tersebut dapat menggunakan kueri paralel. Sebagai contoh lain, anggaplah kueri gabungan menggunakan mekanisme hash join, contohnya untuk menggabungkan tabel besar dengan tabel kecil. Dalam hal ini, pemindaian tabel untuk menghasilkan struktur data filter Bloom mungkin dapat menggunakan kueri paralel.

mysql> explain select count(*) from orders join customer where o_custkey = c_custkey;
+----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+
| id |...| table    | type  | possible_keys | key         |...| rows      | Extra                                                                                                           |
+----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+
|  1 |...| customer | index | PRIMARY       | c_nationkey |...|  15051972 | Using index                                                                                                     |
|  1 |...| orders   | ALL   | o_custkey     | NULL        |...| 154545408 | Using join buffer (Hash Join Outer table orders); Using parallel query (1 columns, 0 filters, 1 exprs; 0 extra) |
+----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+

Untuk kueri gabungan yang menggunakan mekanisme nested loop, blok nested loop terluar mungkin menggunakan kueri paralel. Penggunaan kueri paralel bergantung pada faktor yang sama seperti biasanya, seperti adanya ketentuan filter tambahan dalam klausul WHERE.

mysql> -- Nested loop join with extra filter conditions can use parallel query.
mysql> explain select count(*) from part, partsupp where p_partkey != ps_partkey and p_name is not null and ps_availqty > 0;
+----+-------------+----------+...+----------+----------------------------------------------------------------------------+
| id | select_type | table    |...| rows     | Extra                                                                      |
+----+-------------+----------+...+----------+----------------------------------------------------------------------------+
|  1 | SIMPLE      | part     |...| 20427936 | Using where; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) |
|  1 | SIMPLE      | partsupp |...| 78164450 | Using where; Using join buffer (Block Nested Loop)                         |
+----+-------------+----------+...+----------+----------------------------------------------------------------------------+

Subkueri

Blok kueri luar dan blok subkueri dalam masing-masing dapat menggunakan kueri paralel atau tidak. Untuk setiap blok, menggunakan kueri paralel atau tidak, didasarkan pada karakteristik umum tabel, klausul WHERE, dan sebagainya. Contohnya, kueri berikut menggunakan kueri paralel untuk blok subkueri tetapi tidak untuk blok luar.

mysql> explain select count(*) from part where
   --> p_partkey < (select max(p_partkey) from part where p_name like '%vanilla%');
+----+-------------+...+----------+----------------------------------------------------------------------------+
| id | select_type |...| rows     | Extra                                                                      |
+----+-------------+...+----------+----------------------------------------------------------------------------+
|  1 | PRIMARY     |...|     NULL | Impossible WHERE noticed after reading const tables                        |
|  2 | SUBQUERY    |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
+----+-------------+...+----------+----------------------------------------------------------------------------+

Saat ini, subkueri yang berkorelasi tidak dapat menggunakan pengoptimalan kueri paralel.

UNION

Setiap blok kueri dalam kueri UNION dapat menggunakan kueri paralel atau tidak, berdasarkan karakteristik umum tabel, klausul WHERE, dan sebagainya, untuk setiap bagian UNION.

mysql> explain select p_partkey from part where p_name like '%choco_ate%'
    -> union select p_partkey from part where p_name like '%vanil_a%';
+----+----------------+...+----------+----------------------------------------------------------------------------+
| id | select_type    |...| rows     | Extra                                                                      |
+----+----------------+...+----------+----------------------------------------------------------------------------+
|  1 | PRIMARY        |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
|  2 | UNION          |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) |
| NULL | UNION RESULT | <union1,2> |...|     NULL | Using temporary                                           |
+----+--------------+...+----------+----------------------------------------------------------------------------+

Setiap klausul UNION dalam kueri dijalankan secara berurutan. Bahkan jika kueri mencakup beberapa tahap yang semuanya menggunakan kueri paralel, kueri tersebut hanya menjalankan satu kueri paralel dalam satu waktu. Oleh karena itu, bahkan kueri multitahap yang kompleks hanya dihitung sebagai 1 terhadap batas kueri paralel yang serentak.

Tampilan

Pengoptimal menulis ulang kueri apa pun menggunakan tampilan sebagai kueri yang lebih panjang menggunakan tabel yang mendasarinya. Dengan demikian, kueri paralel bekerja dengan cara yang sama baik referensi tabelnya berupa tampilan atau tabel nyata. Semua pertimbangan yang sama tentang apakah akan menggunakan kueri paralel untuk suatu kueri, dan bagian mana yang diturunkan, berlaku untuk kueri terakhir yang ditulis ulang.

Contohnya, rencana kueri berikut menunjukkan definisi tampilan yang biasanya tidak menggunakan kueri paralel. Saat tampilan dikueri dengan klausul WHERE tambahan , Aurora MySQL menggunakan kueri paralel.

mysql> create view part_view as select * from part;
mysql> explain select count(*) from part_view where p_partkey is not null;
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (1 columns, 0 filters, 0 exprs; 1 extra) |
+----+...+----------+----------------------------------------------------------------------------+

Pernyataan bahasa manipulasi data (DML)

Pernyataan INSERT dapat menggunakan kueri paralel untuk fase pemrosesan SELECT, jika bagian SELECT sesuai dengan ketentuan lainnya untuk kueri paralel.

mysql> create table part_subset like part;
mysql> explain insert into part_subset select * from part where p_mfgr = 'Manufacturer#1';
+----+...+----------+----------------------------------------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+----------------------------------------------------------------------------+
|  1 |...| 20427936 | Using where; Using parallel query (9 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+----------+----------------------------------------------------------------------------+

Biasanya, setelah pernyataan INSERT, data untuk baris yang baru dimasukkan ada di dalam buffer pool. Oleh karena itu, suatu tabel mungkin tidak memenuhi syarat untuk kueri paralel segera setelah memasukkan baris dalam jumlah besar. Lalu, setelah data dikeluarkan dari buffer pool selama operasi normal, kueri terhadap tabel tersebut dapat mulai menggunakan kueri paralel.

Pernyataan CREATE TABLE AS SELECT tidak menggunakan kueri paralel, meskipun bagian SELECT dari pernyataan tersebut akan memenuhi syarat untuk kueri paralel. Aspek DDL dari pernyataan ini menjadikannya tidak kompatibel dengan pemrosesan kueri paralel. Sebaliknya, dalam pernyataan INSERT ... SELECT, bagian SELECT dapat menggunakan kueri paralel.

Kueri paralel tidak pernah digunakan untuk pernyataan DELETE atau UPDATE, terlepas dari ukuran tabel dan predikat dalam klausul WHERE.

mysql> explain delete from part where p_name is not null;
+----+-------------+...+----------+-------------+
| id | select_type |...| rows     | Extra       |
+----+-------------+...+----------+-------------+
|  1 | SIMPLE      |...| 20427936 | Using where |
+----+-------------+...+----------+-------------+

Transaksi dan penguncian

Anda dapat menggunakan semua tingkat isolasi pada instans utama Aurora.

Pada instans pembaca Aurora DB, kueri paralel berlaku untuk pernyataan yang dilakukan dalam tingkat isolasi REPEATABLE READ. Aurora MySQL versi 1.23 dan 2.09 atau lebih tinggi juga dapat menggunakan tingkat isolasi READ COMMITTED pada instans DB pembaca. REPEATABLE READ adalah tingkat isolasi default untuk instans DB pembaca Aurora. Untuk menggunakan tingkat isolasi READ COMMITTED pada instans reader DB membutuhkan pengaturan opsi konfigurasi aurora_read_replica_read_committed pada tingkat sesi. KlasterREAD COMMITTEDtingkat isolasi untuk instans pembaca sesuai dengan perilaku standar SQL. Namun, isolasi kurang ketat pada instance pembaca daripada saat kueri digunakanREAD COMMITTEDtingkat isolasi pada instans penulis.

Untuk informasi lebih lanjut tentang tingkat isolasi Aurora, terutama perbedaan dalamREAD COMMITTEDantara instance penulis dan pembaca, lihatTingkat isolasi Aurora MySQL.

Setelah transaksi besar selesai, statistik tabel mungkin menjadi usang. Statistik yang usang tersebut mungkin memerlukan pernyataan ANALYZE TABLE sebelum Aurora dapat secara akurat memperkirakan jumlah baris. Pernyataan skala besar DML juga dapat memasukkan sebagian besar data tabel ke buffer pool. Memiliki data ini di dalam buffer pool dapat menyebabkan kueri paralel menjadi lebih jarang dipilih untuk tabel tersebut sampai data dikeluarkan dari kumpulan.

Jika sesi Anda berada dalam transaksi yang berlangsung lama (secara default, 10 menit), kueri lebih lanjut di dalam sesi tersebut tidak menggunakan kueri paralel. Waktu habis juga dapat terjadi dalam satu kueri yang berlangsung lama. Jenis waktu habis ini dapat terjadi jika kueri berjalan lebih lama dari interval maksimum (saat ini 10 menit) sebelum pemrosesan kueri paralel dimulai.

Anda dapat mengurangi kemungkinan memulai transaksi yang berlangsung lama secara tidak sengaja dengan mengatur autocommit=1 dalam sesi mysql di mana Anda melakukan kueri ad hoc (satu waktu). Bahkan pernyataan SELECT terhadap suatu tabel akan memulai transaksi dengan membuat tampilan baca. Tampilan baca merupakan rangkaian data yang konsisten untuk kueri berikutnya yang tetap ada hingga transaksi dilakukan. Waspadai pembatasan ini juga saat menggunakan aplikasi JDBC atau ODBC dengan Aurora, karena aplikasi tersebut mungkin berjalan dengan pengaturan autocommit yang tidak aktif.

Contoh berikut ini menunjukkan bagaimana, dengan pengaturan autocommit yang dinonaktifkan, menjalankan suatu kueri terhadap tabel akan menciptakan tampilan baca yang secara implisit memulai transaksi. Kueri yang dijalankan segera sesudahnya masih dapat menggunakan kueri paralel. Namun, setelah jeda beberapa menit, kueri tidak lagi memenuhi syarat untuk kueri paralel. Mengakhiri transaksi dengan COMMIT atau ROLLBACK akan memulihkan eligilibilitas kueri paralel.

mysql> set autocommit=0;

mysql> explain select sql_no_cache count(*) from part where p_retailprice > 10.0;
+----+...+---------+----------------------------------------------------------------------------+
| id |...| rows    | Extra                                                                      |
+----+...+---------+----------------------------------------------------------------------------+
|  1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+---------+----------------------------------------------------------------------------+

mysql> select sleep(720); explain select sql_no_cache count(*) from part where p_retailprice > 10.0;
+------------+
| sleep(720) |
+------------+
|          0 |
+------------+
1 row in set (12 min 0.00 sec)

+----+...+---------+-------------+
| id |...| rows    | Extra       |
+----+...+---------+-------------+
|  1 |...| 2976129 | Using where |
+----+...+---------+-------------+

mysql> commit;

mysql> explain select sql_no_cache count(*) from part where p_retailprice > 10.0;
+----+...+---------+----------------------------------------------------------------------------+
| id |...| rows    | Extra                                                                      |
+----+...+---------+----------------------------------------------------------------------------+
|  1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+---------+----------------------------------------------------------------------------+

Untuk melihat berapa kali kueri tidak memenuhi syarat untuk kueri paralel karena kueri tersebut berada dalam transaksi yang berlangsung lama, periksa variabel status Aurora_pq_request_not_chosen_long_trx.

mysql> show global status like '%pq%trx%';
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| Aurora_pq_request_not_chosen_long_trx | 4     |
+-------------------------------+-------+

Setiap pernyataan SELECT yang memperoleh kunci, seperti sintaks SELECT FOR UPDATE atau SELECT LOCK IN SHARE MODE, tidak dapat menggunakan kueri paralel.

Kueri paralel dapat berfungsi untuk tabel yang dikunci oleh pernyataan LOCK TABLES.

mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk = 'Clerk#000095055';
+----+...+-----------+----------------------------------------------------------------------------+
| id |...| rows      | Extra                                                                      |
+----+...+-----------+----------------------------------------------------------------------------+
|  1 |...| 154545408 | Using where; Using parallel query (3 columns, 1 filters, 0 exprs; 0 extra) |
+----+...+-----------+----------------------------------------------------------------------------+

mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk = 'Clerk#000095055' for update;
+----+...+-----------+-------------+
| id |...| rows      | Extra       |
+----+...+-----------+-------------+
|  1 |...| 154545408 | Using where |
+----+...+-----------+-------------+

Indeks pohon B

Statistik yang dikumpulkan oleh pernyataan ANALYZE TABLE membantu pengoptimal untuk memutuskan waktu untuk menggunakan kueri paralel atau pencarian indeks, berdasarkan karakteristik data untuk setiap kolom. Tetap perbarui statistik dengan menjalankan ANALYZE TABLE setelah operasi DML yang menerapkan perubahan substansial pada data dalam tabel.

Jika pencarian indeks dapat melakukan kueri secara efisien tanpa pemindaian sarat data, Aurora mungkin menggunakan pencarian indeks. Melakukan hal ini akan menghindari pengeluaran tambahan dari pemrosesan kueri paralel. Terdapat juga batas keserentakan pada jumlah kueri paralel yang dapat berjalan secara bersamaan di klaster Aurora DB mana pun. Pastikan Anda menggunakan praktik terbaik untuk mengindeks tabel, sehingga kueri yang paling sering dan paling sering muncul bersamaan menggunakan pencarian indeks.

Indeks pencarian teks penuh (FTS)

Saat ini, kueri paralel tidak digunakan untuk tabel yang berisi indeks pencarian teks penuh, terlepas dari apakah kueri tersebut mengacu pada kolom yang diindeks tersebut atau menggunakan operator MATCH.

Kolom virtual

Saat ini, kueri paralel tidak digunakan untuk tabel yang berisi kolom virtual, terlepas dari apakah kueri tersebut merujuk pada kolom virtual mana pun.

Mekanisme caching bawaan

Aurora mencakup mekanisme caching bawaan, yaitu buffer pool dan cache kueri. Pengoptimal Aurora memilih antara mekanisme caching ini dan kueri paralel bergantung pada mana yang paling efektif untuk kueri tertentu.

Saat kueri paralel memfilter baris dan mengubah serta mengekstraksi nilai kolom, data dikirim kembali ke simpul kepala sebagai urutan dan bukan sebagai halaman data. Oleh karena itu, menjalankan kueri paralel tidak akan menambahkan halaman apa pun ke dalam buffer pool, atau mengeluarkan halaman yang sudah ada di dalam bufer.

Aurora memeriksa jumlah halaman data tabel yang ada dalam buffer pool, dan bagian mana dari data tabel tersebut yang direpresentasikan oleh angka tersebut. Aurora menggunakan informasi tersebut untuk menentukan apakah lebih efisien untuk menggunakan kueri paralel (dan mem-bypass data dalam buffer pool). Sebagai alternatif, Aurora mungkin menggunakan jalur pemrosesan kueri nonparalel, yang menggunakan cache data dalam buffer pool. Halaman mana yang dibuat cache dan bagaimana kueri sarat data dapat memengaruhi caching dan pengeluaran bergantung pada pengaturan konfigurasi yang terkait dengan buffer pool. Oleh karena itu, akan sulit untuk memprediksi apakah kueri tertentu menggunakan kueri paralel, karena pilihannya bergantung pada data yang selalu berubah dalam buffer pool.

Selain itu, Aurora menerapkan batas keserentakan pada kueri paralel. Karena tidak setiap kueri menggunakan kueri paralel, tabel yang diakses oleh beberapa kueri secara serentak biasanya memiliki bagian yang substansial dari data mereka dalam buffer pool. Oleh karena itu, Aurora sering kali tidak memilih tabel ini untuk kueri paralel.

Ketika Anda menjalankan urutan kueri nonparalel pada tabel yang sama, kueri pertama mungkin lambat karena data tidak ada dalam buffer pool. Lalu kueri kedua dan selanjutnya jauh lebih cepat karena buffer pool sekarang sudah "dipanaskan". Kueri paralel biasanya menunjukkan kinerja yang konsisten dari kueri pertama terhadap tabel. Saat melakukan uji kinerja, buat tolok ukur kueri nonparalel dengan buffer pool yang dingin dan hangat. Dalam beberapa kasus, hasil dari buffer pool hangat dapat menghasilkan perbandingan yang baik dengan waktu kueri paralel. Dalam kasus ini, pertimbangkan faktor seperti frekuensi kueri terhadap tabel tersebut. Pertimbangkan juga apakah bermanfaat untuk menyimpan data untuk tabel tersebut di dalam buffer pool.

Cache kueri menghindari menjalankan ulang kueri saat kueri yang identik dikirimkan dan data tabel yang mendasarinya tidak berubah. Kueri yang dioptimalkan dengan fitur kueri paralel dapat masuk ke cache kueri, yang secara efektif menjadikannya instan saat dijalankan lagi.

Saat melakukan perbandingan kinerja, cache kueri dapat menghasilkan jumlah pengaturan waktu yang rendah secara buatan. Oleh karena itu, dalam situasi serupa tolok ukur, Anda dapat menggunakan petunjuk sql_no_cache. Petunjuk ini mencegah hasil tersebut tersaji dari cache kueri, meskipun kueri yang sama telah dijalankan sebelumnya. Petunjuk segera muncul setelah pernyataan SELECT dalam kueri. Banyak contoh kueri parallel dalam topik ini mencakup petunjuk ini, untuk membuat waktu kueri yang sebanding antara versi kueri parallel diaktifkan dan dinonaktifkan.

Pastikan Anda menghapus petunjuk ini dari sumber Anda saat beralih ke penggunaan kueri paralel untuk produksi.

Tabel sementara MyISAM

Pengoptimalan kueri paralel hanya berlaku untuk tabel InnoDB. Karena Aurora MySQL menggunakan MyISAM di balik layar untuk tabel sementara, fase kueri internal yang mencakup tabel sementara tidak pernah menggunakan kueri paralel. Fase kueri ini ditunjukkan oleh Using temporary dalam output EXPLAIN.