Ikhtisar kueri paralel Merencanakan klaster kueri paralel Membuat klaster kueri paralel Mengaktifkan dan menonaktifkan kueri paralel Meningkatkan klaster kueri paralel Penyempurnaan kinerja Membuat objek skema Memverifikasi penggunaan kueri paralel Memantau Kueri paralel dan konsep SQL

Bekerja dengan kueri paralel untuk Amazon Aurora MySQL

Topik ini menjelaskan pengoptimalan kinerja kueri paralel untuk Edisi yang Kompatibel dengan Amazon Aurora MySQL. Fitur ini menggunakan jalur pemrosesan khusus untuk kueri tertentu yang sarat data, dengan 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.

Daftar Isi

Ikhtisar kueri paralel untuk Aurora MySQL

Kueri paralel Aurora MySQL adalah pengoptimalan yang memaralelkan beberapa I/O dan komputasi yang terlibat dalam pemrosesan kueri sarat data. Pekerjaan yang diparalelkan mencakup pengambilan baris dari penyimpanan, ekstraksi nilai kolom, dan penentuan baris yang cocok dengan ketentuan dalam klausa WHERE dan klausa sambungan. Pekerjaan sarat data ini didelegasikan (dalam istilah pengoptimalan basis data, ditekan) ke beberapa simpul di lapisan penyimpanan terdistribusi Aurora. Tanpa kueri paralel, setiap kueri membawa semua data yang dipindai ke simpul tunggal dalam klaster Aurora MySQL (simpul kepala) dan melakukan semua pemrosesan kueri di sana.

Tip

Mesin basis data PostgreSQL juga memiliki fitur yang disebut “kueri paralel.” Fitur tersebut tidak terkait dengan kueri paralel Aurora.

Saat fitur kueri paralel 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.

catatan

Pengoptimalan kueri paralel sangat menguntungkan bagi kueri yang berlangsung lama yang memerlukan waktu beberapa menit atau jam untuk diselesaikan. 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 mendapati kueri paralel tidak digunakan seperti yang Anda harapkan, lihat Memverifikasi pernyataan mana yang menggunakan kueri paralel.

Manfaat

Dengan kueri paralel, Anda dapat menjalankan kueri analitik sarat data pada tabel Aurora MySQL. Dalam banyak kasus, Anda dapat memperoleh peningkatan kinerja yang jauh lebih besar melalui pemisahan tugas untuk pemrosesan kueri.

Manfaat kueri paralel antara lain:

Meningkatkan kinerja I/O, karena paralelisasi permintaan baca fisik di 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 hanya berisi nilai kolom yang diperlukan untuk set hasil.
Mengurangi penggunaan CPU pada simpul kepala, karena menekan pemrosesan fungsi, penyaringan baris, dan proyeksi kolom untuk klausa WHERE.
Menurunkan tekanan memori pada pool buffer. Halaman yang diproses oleh kueri paralel tidak ditambahkan ke dalam pool buffer. Pendekatan ini mengurangi peluang pemindaian sarat data mengosongkan data yang sering digunakan dari pool buffer.
Berpotensi mengurangi duplikasi data dalam alur ekstrak, transformasi, muat (ETL) Anda, dengan memudahkan pelaksanaan 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 pemrosesan log redo. Kueri paralel menerapkan prinsip yang sama untuk operasi baca.

catatan

Arsitektur kueri paralel Aurora MySQL berbeda dari arsitektur dengan nama fitur yang mirip di sistem basis data lain. Kueri paralel Aurora MySQL tidak mencakup multipemrosesan simetris (SMP) sehingga tidak bergantung pada kapasitas CPU server basis data. 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 di dalam klaster Aurora (simpul kepala). Aurora kemudian melakukan semua pemrosesan lebih lanjut untuk kueri tersebut di dalam thread tunggal pada simpul tunggal tersebut. Dengan kueri paralel, banyak 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 diperlukan klaster DB Aurora MySQL yang menjalankan versi 2.09 atau lebih tinggi. Jika Anda sudah memiliki klaster yang ingin Anda gunakan dengan kueri paralel, Anda dapat meningkatkannya ke versi yang kompatibel dan mengaktifkan kueri paralel 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.

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

Pastikan bahwa pengoptimalan hash join diaktifkan untuk klaster Anda. Untuk mempelajari caranya, lihat Mengaktifkan hash join untuk klaster kueri paralel.

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.

Pembatasan

Batasan berikut berlaku untuk fitur kueri paralel:

Kueri paralel tidak didukung dengan konfigurasi penyimpanan klaster DB Aurora I/O-Optimized.
Anda tidak dapat menggunakan kueri paralel dengan kelas instans db.t2 atau db.t3. Batasan ini berlaku bahkan jika Anda meminta kueri paralel menggunakan variabel session aurora_pq_force.
Kueri paralel tidak berlaku pada tabel yang menggunakan format baris COMPRESSED atau REDUNDANT. Gunakan format baris COMPACT atau DYNAMIC untuk tabel yang akan Anda gunakan dengan kueri paralel.
Aurora menggunakan algoritma berbasis biaya untuk menentukan apakah akan menggunakan mekanisme kueri paralel untuk setiap pernyataan SQL. Menggunakan konsep SQL tertentu dalam pernyataan dapat mencegah kueri paralel atau menjadikan kueri paralel tidak memungkinkan untuk pernyataan tersebut. Untuk informasi tentang kompatibilitas konsep SQL dengan kueri paralel, lihat Cara kerja kueri paralel dengan konsep 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, sambungan, 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 Aurora MySQL minimum yang diperlukan untuk menggunakan kueri paralel adalah 2.09.
Kueri paralel dirancang untuk meningkatkan kinerja kueri sarat data. Ini tidak dirancang untuk kueri ringan.
Kami menyarankan Anda menggunakan simpul pembaca untuk pernyataan SELECT, terutama yang sarat data.

Biaya I/O dengan kueri paralel

Jika klaster Aurora MySQL Anda menggunakan kueri paralel, Anda mungkin melihat peningkatan nilai VolumeReadIOPS. Kueri paralel tidak menggunakan kumpulan buffer. Jadi, meskipun kueri cepat, pemrosesan yang dioptimalkan ini dapat menghasilkan peningkatan operasi baca dan biaya terkait.

Biaya I/O kueri paralel untuk kueri Anda diukur pada lapisan penyimpanan, dan akan sama atau lebih besar dengan saat kueri paralel diaktifkan. Anda akan mendapat manfaat berupa peningkatan kinerja kueri. Ada dua alasan untuk biaya I/O yang berpotensi lebih tinggi dengan kueri paralel:

Bahkan jika beberapa data dalam tabel berada di pool buffer, kueri paralel mengharuskan semua data dipindai di lapisan penyimpanan, sehingga menimbulkan biaya I/O.
Menjalankan kueri paralel tidak menyiapkan pool buffer. Akibatnya, menjalankan kueri paralel yang sama secara berurutan menimbulkan biaya I/O penuh.

Merencanakan klaster kueri paralel

Perencanaan untuk klaster DB dengan kueri paralel yang diaktifkan mengharuskan beberapa pilihan. Termasuk di antaranya adalah melakukan langkah penyiapan (baik membuat maupun memulihkan klaster Aurora MySQL penuh) dan memutuskan seberapa luas pengaktifan kueri paralel di seluruh klaster DB Aurora Anda.

Pertimbangkan hal berikut sebagai bagian dari perencanaan:

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 paralel menggunakan parameter aurora_parallel_query.

Jika Anda memiliki klaster Aurora MySQL yang menjalankan versi 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 mengaktifkan parameter aurora_parallel_query. 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 detailnya, 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-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.7.mysql_aurora.2.11.1
8.0.mysql_aurora.3.01.0
8.0.mysql_aurora.3.01.1
8.0.mysql_aurora.3.02.0
8.0.mysql_aurora.3.02.1
8.0.mysql_aurora.3.02.2
8.0.mysql_aurora.3.03.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 DB Amazon Aurora.

Saat Anda memilih versi mesin Aurora MySQL, sebaiknya Anda memilih versi terbaru. Saat ini, Aurora MySQL versi 2.09 dan lebih tinggi mendukung kueri paralel. Anda memiliki fleksibilitas lebih besar untuk mengaktifkan dan menonaktifkan kueri paralel, atau menggunakan kueri paralel dengan klaster yang ada, jika Anda menggunakan Aurora MySQL 2.09 dan versi lebih tinggi.

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

Ikuti prosedur AWS Management Console umum dalam Membuat klaster DB Amazon Aurora.
Pada layar Pilih mesin, pilih Aurora MySQL.

Untuk Versi mesin, pilih Aurora MySQL 2.09 atau lebih tinggi. Dengan versi ini, 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.
Untuk Konfigurasi tambahan, pilih grup parameter yang Anda buat untuk grup parameter klaster DB. Penggunaan grup parameter kustom tersebut diperlukan untuk Aurora MySQL 2.09 dan yang lebih tinggi. Di grup parameter klaster DB Anda, tentukan pengaturan parameter aurora_parallel_query=ON dan aurora_disable_hash_join=OFF. Tindakan tersebut akan mengaktifkan kueri paralel untuk klaster, dan mengaktifkan pengoptimalan hash join yang bekerja bersama kueri paralel.

Untuk memverifikasi bahwa klaster baru dapat menggunakan kueri paralel

Buat klaster menggunakan teknik sebelumnya.

(Untuk Aurora MySQL versi 2 atau 3) Pastikan pengaturan konfigurasi aurora_parallel_query true.


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

(Untuk Aurora MySQL versi 2) Pastikan pengaturan aurora_disable_hash_join false.


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

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 dalam 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

(Opsional) Perika 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.

(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 Mengaktifkan dan menonaktifkan kueri paralel.

Ikuti prosedur AWS CLI umum dalam Membuat klaster DB Amazon Aurora.
Tentukan rangkaian opsi berikut:
- Untuk opsi --engine, gunakan aurora-mysql. Nilai ini menghasilkan klaster kueri paralel yang kompatibel dengan MySQL 5.7 atau 8.0.
- 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. Gunakan setidaknya versi 2.09.0. Versi ini dan semua versi yang lebih tinggi berisi peningkatan substansial untuk kueri paralel.
  
  Contoh kode berikut menunjukkan caranya. Ganti nilai Anda sendiri untuk setiap variabel lingkungan seperti $CLUSTER_ID. Contoh ini juga menentukan opsi --manage-master-user-password untuk menghasilkan kata sandi pengguna master dan mengelolanya di Secrets Manager. Untuk informasi selengkapnya, lihat Manajemen kata sandi dengan dan AWS Secrets Manager. Alternatifnya, Anda dapat menggunakan opsi --master-password untuk menentukan dan mengelola kata sandi sendiri.
```
aws rds create-db-cluster --db-cluster-identifier $CLUSTER_ID \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --master-username $MASTER_USER_ID --manage-master-user-password \
  --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
```
Verifikasi bahwa klaster yang Anda buat atau pulihkan memiliki fitur kueri paralel yang tersedia.

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 |
+------------------------+
```

Untuk memulihkan snapshot ke klaster kueri paralel dengan AWS CLI

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. Pilih Aurora MySQL 2.09.0 atau lebih tinggi untuk klaster yang kompatibel dengan MySQL 5.7.
Temukan snapshot klaster yang kompatibel dengan Aurora MySQL.

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


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

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.

Mengaktifkan dan menonaktifkan kueri paralel

Saat kueri paralel diaktifkan, Aurora MySQL menentukan apakah akan menggunakannya saat runtime untuk setiap kueri. Dalam hal sambungan, paduan, subkueri, dan sebagainya, Aurora MySQL menentukan apakah akan menggunakan kueri paralel pada runtime untuk setiap blok kueri. Untuk detailnya, lihat Memverifikasi pernyataan mana yang menggunakan kueri paralel dan Cara kerja kueri paralel dengan konsep SQL.

Anda dapat mengaktifkan dan menonaktifkan kueri paralel secara dinamis pada tingkat global dan sesi untuk instans DB menggunakan opsi aurora_parallel_query. 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 paralel 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 Menggunakan grup parameter. Ikuti langkah-langkah ini:

Buat grup parameter klaster kustom (disarankan) atau grup parameter DB kustom.
Dalam grup parameter ini, perbarui parallel_query dengan nilai yang Anda inginkan.
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.

Tip
Karena aurora_parallel_query adalah parameter dinamis, parameter ini tidak memerlukan mulai ulang klaster setelah pengaturan ini diubah. Namun, koneksi apa pun yang menggunakan kueri paralel sebelum beralih opsi akan terus melakukannya sampai koneksi ditutup, atau instans di-boot ulang.

Anda dapat mengubah parameter kueri paralel dengan menggunakan operasi API ModifyDBClusterParameterGroup atau ModifyDBParameterGroup atau AWS Management Console.

Mengaktifkan hash join untuk klaster kueri paralel

Kueri paralel biasanya digunakan untuk jenis kueri sarat sumber daya yang diuntungkan dari pengoptimalan hash join. Oleh karena itu, sebaiknya pastikan hash join diaktifkan untuk klaster yang Anda rencanakan akan menggunakan kueri paralel. Untuk informasi tentang cara menggunakan hash join secara efektif, lihat Mengoptimalkan kueri join MySQL Aurora besar dengan hash join.

Mengaktifkan dan menonaktifkan kueri paralel menggunakan konsol

Anda dapat mengaktifkan atau menonaktifkan kueri paralel pada tingkat instans DB atau tingkat klaster DB dengan menggunakan grup parameter.

Untuk mengaktifkan atau menonaktifkan kueri paralel untuk klaster DB dengan AWS Management Console

Buat grup parameter khusus, seperti yang dijelaskan di Menggunakan grup parameter.
Perbarui aurora_parallel_query ke 1 (diaktifkan) atau 0 (dinonaktifkan). Untuk klaster dengan fitur kueri paralel yang tersedia, aurora_parallel_query dinonaktifkan secara default.
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 DB 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.

Mengaktifkan dan menonaktifkan kueri paralel 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.

Untuk mengaktifkan atau menonaktifkan kueri paralel 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.



$ 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"
}

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

Anda juga dapat mengaktifkan atau menonaktifkan kueri paralel pada tingkat sesi, misalnya melalui baris perintah mysql 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.

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

Menimpa pengoptimal kueri paralel

Anda dapat menggunakan variabel sesi aurora_pq_force untuk menimpa pengoptimal kueri paralel dan meminta kueri paralel untuk setiap kueri. Kami menyarankan Anda melakukan tindakan ini hanya untuk tujuan pengujian. Contoh berikut ini menunjukkan cara menggunakan aurora_pq_force dalam sebuah sesi.


set SESSION aurora_parallel_query = ON;
set SESSION aurora_pq_force = ON;

Untuk mematikan penimpaan, lakukan hal berikut:


set SESSION aurora_pq_force = OFF;

Pertimbangan peningkatan untuk kueri paralel

Tergantung versi asal dan tujuan saat Anda meningkatkan versi klaster kueri paralel, Anda mungkin menemukan penyempurnaan dalam jenis kueri yang dapat dioptimalkan oleh kueri paralel. Anda mungkin juga menemukan bahwa Anda tidak perlu menentukan parameter mode mesin khusus untuk kueri paralel. Bagian berikutnya menjelaskan pertimbangan saat Anda meningkatkan klaster dengan kueri paralel yang diaktifkan.

Meningkatkan klaster kueri paralel ke Aurora MySQL versi 3

Beberapa pernyataan, klausa, dan tipe data SQL memiliki dukungan kueri paralel baru atau yang lebih baik dimulai di Aurora MySQL versi 3. Saat Anda melakukan peningkatan dari rilis sebelum versi 3, periksa apakah kueri tambahan dapat memperoleh manfaat dari pengoptimalan kueri paralel. Untuk informasi tentang penyempurnaan kueri paralel ini, lihat Jenis data kolom, Tabel yang dipartisi, dan Fungsi agregat, klausa GROUP BY, dan klausa HAVING.

Jika Anda meningkatkan klaster kueri paralel dari Aurora MySQL 2.08 atau yang lebih rendah, pelajari juga tentang perubahan cara mengaktifkan kueri paralel. Untuk mempelajarinya, baca Peningkatan ke Aurora MySQL 2.09 dan yang lebih tinggi.

Di Aurora MySQL versi 3, pengoptimalan hash join diaktifkan secara default. Opsi konfigurasi aurora_disable_hash_join dari versi sebelumnya tidak digunakan.

Peningkatan ke Aurora MySQL 2.09 dan yang lebih tinggi

Di Aurora MySQL versi 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 minor atau tingkat patch 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 2.09 atau lebih tinggi.

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

Secara khusus, Anda mengaktifkan kueri paralel dengan menggunakan parameter konfigurasi aurora_parallel_query=ON dan aurora_disable_hash_join=OFF, bukan aurora_pq_supported dan aurora_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, bukan 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 sebelumnya, Anda memeriksa keberadaan parallelquery dalam daftar SupportedEngineModes.

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

Wawasan Performa. Untuk informasi selengkapnya, lihat Memantau muatan DB dengan Wawasan Performa di Amazon Aurora.
Pelacakan Mundur. Untuk informasi selengkapnya, lihat Melakukan backtracking klaster DB Aurora.
Menghentikan 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 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 paralel agar diterapkan pada kueri yang Anda harapkan. Untuk mempelajari caranya, lihat Cara kerja kueri paralel dengan konsep 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 Pembatasan.

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 basis data.

Sebelum mengubah skema Anda untuk mengaktifkan kueri paralel 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 dengan sasaran Anda.

Sebagai contoh, sebelum beralih dari ROW_FORMAT=Compressed ke 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, klausa, dan ekspresi SQL memengaruhi output EXPLAIN untuk kueri paralel, lihat Cara kerja kueri paralel dengan konsep SQL.

Contoh berikut menunjukkan perbedaan antara rencana kueri tradisional dan rencana kueri paralel. Rencana explain ini 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) |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+

Untuk Aurora MySQL versi 3, Anda mengaktifkan hash join pada tingkat sesi dengan mengeluarkan pernyataan berikut.


SET optimizer_switch='block_nested_loop=on';

Untuk Aurora MySQL versi 2.09 dan yang lebih tinggi, Anda mengatur parameter DB aurora_disable_hash_join atau parameter klaster DB ke 0 (off). Jika aurora_disable_hash_join dinonaktifkan, nilai optimizer_switch berubah menjadi hash_join=on.

Setelah Anda mengaktifkan hash join, coba jalankan pernyataan EXPLAIN lagi. Untuk informasi tentang cara menggunakan hash join secara efektif, lihat Mengoptimalkan kueri join MySQL Aurora besar dengan hash join.

Dengan hash join diaktifkan tetapi kueri paralel dinonaktifkan, kueri mungkin memiliki rencana seperti berikut, yang menggunakan hash join, tetapi tidak menggunakan kueri paralel.


+----+-------------+----------+...+-----------+-----------------------------------------------------------------+
| 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 paralel diaktifkan, dua langkah dalam rencana kueri paralel, seperti ditunjukkan pada kolom Extra dalam output EXPLAIN. 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 konsep 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.

catatan

Karena waktu ditentukan oleh 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

Selain metrik Amazon CloudWatch yang dijelaskan dalam Melihat 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 paralel tidak selalu berupa pemetaan satu-ke-satu dengan kueri yang dilakukan oleh basis data. 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 tempat kueri paralel 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.

Nama	Deskripsi
`Aurora_pq_bytes_returned`	Jumlah byte untuk struktur data tuple yang ditransmisikan ke simpul head selama kueri paralel. Bagi dengan 16.384 untuk membandingkan dengan `Aurora_pq_pages_pushed_down`.
`Aurora_pq_max_concurrent_requests`	Jumlah maksimum sesi kueri paralel yang dapat berjalan secara konkuren di instans Aurora DB ini. Ini adalah jumlah tetap yang bergantung pada kelas instans DB AWS.
`Aurora_pq_pages_pushed_down`	Jumlah halaman data (masing-masing dengan ukuran tetap 16 KiB) tempat kueri paralel menghindari transmisi jaringan ke simpul head.
`Aurora_pq_request_attempted`	Jumlah sesi kueri paralel yang diminta. Nilai ini dapat menunjukkan lebih dari satu sesi per kueri, bergantung pada konsep SQL seperti subkueri dan penggabungan.
`Aurora_pq_request_executed`	Jumlah sesi kueri paralel yang berhasil berjalan.
`Aurora_pq_request_failed`	Jumlah sesi kueri paralel yang menampilkan kesalahan kepada klien. Dalam beberapa kasus, permintaan untuk kueri paralel mungkin gagal, misalnya karena masalah dalam lapisan penyimpanan. Dalam kasus ini, bagian kueri yang gagal dicoba kembali menggunakan mekanisme kueri nonparalel. Jika kueri yang dicoba kembali juga gagal, kesalahan ditampilkan ke klien dan penghitung ini ditambah.
`Aurora_pq_request_in_progress`	Jumlah sesi kueri paralel yang sedang berlangsung. Angka ini berlaku untuk instans Aurora DB tertentu yang Anda hubungkan, bukan seluruh klaster Aurora DB. Untuk melihat apakah instans DB mendekati batas konkurensinya, bandingkan nilai ini dengan `Aurora_pq_max_concurrent_requests`.
`Aurora_pq_request_not_chosen`	Berapa kali kueri paralel tidak dipilih untuk memenuhi suatu kueri. Nilai ini adalah jumlah dari beberapa penghitung granular lainnya. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan.
`Aurora_pq_request_not_chosen_below_min_rows`	Berapa kali kueri paralel tidak dipilih karena jumlah baris dalam tabel. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan.
`Aurora_pq_request_not_chosen_column_bit`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena jenis data yang tidak didukung dalam daftar kolom yang diproyeksikan.
`Aurora_pq_request_not_chosen_column_geometry`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel memiliki kolom dengan jenis data `GEOMETRY`. Untuk informasi tentang versi Aurora MySQL yang menghapus batasan ini, lihat Meningkatkan klaster kueri paralel ke Aurora MySQL versi 3.
`Aurora_pq_request_not_chosen_column_lob`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel memiliki kolom dengan jenis data `LOB`, atau kolom `VARCHAR` yang disimpan secara eksternal karena panjang yang dinyatakan. Untuk informasi tentang versi Aurora MySQL yang menghapus batasan ini, lihat Meningkatkan klaster kueri paralel ke Aurora MySQL versi 3.
`Aurora_pq_request_not_chosen_column_virtual`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel berisi kolom virtual.
`Aurora_pq_request_not_chosen_custom_charset`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel memiliki kolom dengan set karakter kustom.
`Aurora_pq_request_not_chosen_fast_ddl`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel saat ini sedang diubah oleh pernyataan `ALTER` DDL cepat.
`Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool`	Berapa kali kueri paralel tidak dipilih, meskipun kurang dari 95 persen data tabel berada di dalam pool buffer, karena data tabel yang tidak di-buffer tidak cukup untuk membuat kueri paralel layak dijalankan.
`Aurora_pq_request_not_chosen_full_text_index`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel memiliki indeks teks penuh.
`Aurora_pq_request_not_chosen_high_buffer_pool_pct`	Berapa kali kueri paralel tidak dipilih karena persentase tinggi data tabel (saat ini, lebih dari 95 persen) sudah berada di dalam pool buffer. Dalam kasus ini, pengoptimal menentukan bahwa membaca data dari pool buffer akan lebih efisien. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan.
`Aurora_pq_request_not_chosen_index_hint`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri mencakup petunjuk indeks.
`Aurora_pq_request_not_chosen_innodb_table_format`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena tabel menggunakan format baris InnoDB yang tidak didukung. Kueri paralel Aurora hanya berlaku untuk format baris `COMPACT`, `REDUNDANT`, dan `DYNAMIC`.
`Aurora_pq_request_not_chosen_long_trx`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri dimulai di dalam transaksi yang berjalan lama. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan.
`Aurora_pq_request_not_chosen_no_where_clause`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri tidak mencakup klausa `WHERE` apa pun.
`Aurora_pq_request_not_chosen_range_scan`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri menggunakan pemindaian rentang pada indeks.
`Aurora_pq_request_not_chosen_row_length_too_long`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena total panjang gabungan semua kolom terlalu panjang.
`Aurora_pq_request_not_chosen_small_table`	Berapa kali kueri paralel tidak dipilih karena ukuran keseluruhan tabel, sebagaimana ditentukan oleh jumlah baris dan rata-rata panjang baris. Pernyataan `EXPLAIN` dapat menambah penghitung ini meskipun kueri tidak benar-benar dilakukan.
`Aurora_pq_request_not_chosen_temporary_table`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri mengacu pada tabel sementara yang menggunakan jenis tabel `MyISAM` atau `memory` yang tidak didukung.
`Aurora_pq_request_not_chosen_tx_isolation`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri menggunakan tingkat isolasi transaksi yang tidak didukung. Pada instans pembaca DB, kueri paralel hanya berlaku untuk tingkat isolasi `REPEATABLE READ` dan `READ COMMITTED`.
`Aurora_pq_request_not_chosen_update_delete_stmts`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena kueri adalah bagian dari pernyataan `UPDATE` atau `DELETE`.
`Aurora_pq_request_not_chosen_unsupported_access`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena klausa `WHERE` tidak memenuhi kriteria untuk kueri paralel. Hasil ini dapat muncul jika kueri tidak memerlukan pemindaian sarat data, atau jika kueri adalah pernyataan `DELETE` atau `UPDATE`.
`Aurora_pq_request_not_chosen_unsupported_storage_type`	Jumlah permintaan kueri paralel yang menggunakan jalur pemrosesan kueri nonparalel karena klaster Aurora MySQL DB tidak menggunakan konfigurasi penyimpanan klaster Aurora MySQL yang didukung. Parameter ini tersedia di Aurora MySQL versi 3.04 dan lebih tinggi. Untuk informasi selengkapnya, lihat Pembatasan.
`Aurora_pq_request_throttled`	Berapa kali kueri paralel tidak dipilih karena jumlah maksimum kueri paralel konkuren sudah berjalan pada instans Aurora DB tertentu.

Cara kerja kueri paralel dengan konsep SQL

Pada bagian berikut, Anda dapat menemukan detail lebih lanjut tentang alasan pernyataan 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.

Tip

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

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 klausa WHERE. Dua klausa WHERE memerlukan evaluasi ekspresi yang lebih rumit, dalam hal ini mencakup panggilan fungsi. Bidang 0 extra mengonfirmasi bahwa semua operasi dalam klausa 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 EXPLAIN lain. 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 sebuah kueri di mana pengoptimal dapat memperkirakan bahwa kueri tersebut hanya akan memindai sejumlah kecil baris. Hal itu dilakukan berdasarkan karakteristik kunci primer. 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 mempertimbangkan semua faktor yang tersedia saat pernyataan EXPLAIN dijalankan. Pengoptimal mungkin mengambil pilihan lain saat kueri benar-benar dijalankan, jika situasi berubah pada saat itu. Contohnya, EXPLAIN dapat melaporkan bahwa suatu pernyataan akan menggunakan kueri paralel. Namun saat kueri benar-benar dijalankan nantinya, 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.

Klausa WHERE

Agar menggunakan pengoptimalan kueri paralel, suatu kueri harus mencakup klausa WHERE.

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

Perbandingan sederhana antara nilai kolom dengan konstanta, yang disebut filter. Perbandingan ini sangat diuntungkan ketika diturunkan ke lapisan penyimpanan. Jumlah ekspresi filter dalam sebuah kueri dilaporkan dalam output EXPLAIN.
Jenis ekspresi lain dalam klausa WHERE juga diturunkan ke lapisan penyimpanan jika memungkinkan. Jumlah ekspresi tersebut dalam sebuah 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 sebuah 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 klausa 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 baris yang dikembalikan untuk suatu blok kueri jumlahnya kecil, kueri paralel tidak digunakan untuk blok kueri tersebut. Contoh berikut menunjukkan kasus di mana operator lebih-besar-daripada di kolom kunci primer berlaku untuk jutaan baris, yang menyebabkan kueri paralel digunakan. Pengujian 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)

Di Aurora MySQL versi 2, kueri paralel hanya tersedia untuk tabel yang tidak memiliki operasi bahasa definisi data (DDL) cepat yang tertunda. Di Aurora MySQL versi 3, Anda dapat menggunakan kueri paralel untuk suatu tabel pada saat yang sama dengan operasi DDL instan.

DDL instan di Aurora MySQL versi 3 menggantikan fitur DDL cepat di Aurora MySQL versi 2. Untuk informasi tentang DDL, lihat DDL instan (Aurora MySQL versi 3).

Jenis data kolom

Di Aurora MySQL versi 3, kueri paralel dapat bekerja dengan tabel yang berisi kolom dengan tipe data TEXT, BLOB, JSON, dan GEOMETRY. Ini juga dapat bekerja dengan kolom VARCHAR dan CHAR dengan panjang maksimum yang dinyatakan melebihi 768 byte. Jika kueri Anda mengacu pada kolom yang berisi jenis objek besar seperti itu, tugas tambahan untuk mengambilnya akan memunculkan overhead ke dalam pemrosesan kueri. Dalam hal ini, periksa apakah kueri dapat menghilangkan referensi ke kolom-kolom tersebut. Jika tidak, jalankan tolok ukur untuk mengonfirmasi apakah kueri tersebut lebih cepat dengan kueri paralel diaktifkan atau dinonaktifkan.

Di Aurora MySQL versi 2, kueri paralel memiliki batasan-batasan tersebut untuk jenis objek besar:

Jenis data TEXT, BLOB, JSON, dan GEOMETRY tidak didukung dengan kueri paralel. Kueri yang mengacu pada kolom apa pun dari jenis ini tidak dapat menggunakan kueri paralel.
Kolom dengan panjang variabel (jenis data VARCHAR dan CHAR) kompatibel dengan kueri paralel hingga panjang maksimum yang dinyatakan 768 byte. 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 paralel di Aurora MySQL versi 3. Karena tabel yang dipartisi direpresentasikan secara internal sebagai beberapa tabel yang lebih kecil, kueri yang menggunakan kueri paralel pada tabel yang tidak dipartisi mungkin tidak menggunakan kueri paralel pada tabel yang dipartisi identik. Aurora MySQL mempertimbangkan apakah setiap partisi cukup besar untuk memenuhi syarat optimasi kueri paralel, bukan mengevaluasi ukuran seluruh tabel. Periksa apakah variabel status Aurora_pq_request_not_chosen_small_table bertambah jika kueri pada tabel yang dipartisi tidak menggunakan kueri paralel padahal Anda mengharapkannya.

Misalnya, pertimbangkan satu tabel yang dipartisi dengan PARTITION BY HASH (column) PARTITIONS 2 dan tabel lain dipartisi dengan PARTITION BY HASH (column) PARTITIONS 10. Dalam tabel dengan dua partisi, partisinya lima kali lebih besar daripada tabel dengan sepuluh partisi. Dengan demikian, kueri paralel lebih memungkinkan untuk digunakan untuk mengkueri tabel dengan lebih sedikit partisi. Dalam contoh berikut, tabel PART_BIG_PARTITIONS memiliki dua partisi dan PART_SMALL_PARTITIONS memiliki sepuluh partisi. Dengan data yang identik, kueri paralel lebih memungkinkan untuk digunakan untuk tabel dengan lebih sedikit partisi besar.



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, klausa GROUP BY, dan klausa 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, kueri paralel dapat mengoptimalkan panggilan fungsi agregat dalam daftar pilih dan klausa HAVING.

Sebelum Aurora MySQL 3, panggilan fungsi agregat dalam daftar pilih atau klausa HAVING tidak ditekan 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 klausa WHERE

Aurora dapat menerapkan pengoptimalan kueri paralel pada panggilan ke sebagian besar fungsi bawaan dalam klausa WHERE. Paralelisasi panggilan fungsi ini melimpahkan beberapa pekerjaan CPU dari simpul kepala. Mengevaluasi fungsi predikat secara paralel selama tahap kueri paling awal 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 klausa 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 klausa WHERE. Kueri paralel tidak memengaruhi panggilan ke 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. Misalnya, contoh berikut menunjukkan bahwa kueri paralel mengevaluasi ekspresi CASE dan operator LIKE di klausa 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) |
+----+...+-------------------------------------------------------------------------------------------------------------+

Klausa LIMIT

Saat ini, kueri paralel tidak digunakan untuk blok kueri yang mencakup klausa LIMIT. Kueri paralel masih dapat digunakan untuk fase kueri sebelumnya dengan GROUP by, 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 primer 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 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.

Gabungan

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 klausa WHERE. Oleh karena itu, kueri gabungan adalah pengecualian untuk aturan bahwa klausa 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.

catatan

Kueri paralel biasanya digunakan untuk jenis kueri sarat sumber daya yang diuntungkan dari pengoptimalan hash join. Metode untuk mengaktifkan optimasi hash join ditentukan oleh versi Aurora MySQL. Untuk detail untuk setiap versi, lihat Mengaktifkan hash join untuk klaster kueri paralel. Untuk informasi tentang cara menggunakan hash join secara efektif, lihat Mengoptimalkan kueri join MySQL Aurora besar dengan hash join.


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 klausa 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, klausa 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, klausa 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                                           |
+----+--------------+...+----------+----------------------------------------------------------------------------+

catatan

Setiap klausa 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 klausa 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) |
+----+...+----------+----------------------------------------------------------------------------+

catatan

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 dikosongkan 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 klausa 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 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. Tingkat isolasi READ COMMITTED untuk instans pembaca sesuai dengan perilaku standar SQL. Namun, isolasi ini lebih longgar pada instans pembaca dibandingkan ketika kueri menggunakan tingkat isolasi READ COMMITTED pada instans penulis.

Untuk informasi lebih lanjut tentang tingkat isolasi Aurora, terutama perbedaan dalam hal READ COMMITTED antara instans penulis dan pembaca, lihat Tingkat 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 dikosongkan dari pool.

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 mengosongkan halaman yang sudah ada di dalam buffer pool.

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 pengosongan 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.

catatan

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 paralel dalam topik ini mencakup petunjuk ini, untuk menjadikan waktu kueri sebanding antara versi kueri dengan kueri paralel yang diaktifkan dan dinonaktifkan.

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

Petunjuk pengoptimal

Cara lain untuk mengontrol pengoptimal adalah dengan menggunakan petunjuk pengoptimal, yang dapat ditentukan dalam pernyataan individual. Misalnya, Anda dapat mengaktifkan pengoptimalan untuk satu tabel dalam sebuah pernyataan, kemudian mematikan pengoptimalan untuk tabel yang berbeda. Untuk informasi selengkapnya tentang petunjuk ini, lihat Petunjuk Pengoptimal di Panduan Referensi MySQL.

Anda dapat menggunakan petunjuk SQL dengan kueri Aurora MySQL untuk kinerja yang sempurna. Anda juga dapat menggunakan petunjuk agar rencana eksekusi untuk kueri penting tidak berubah karena kondisi yang tidak dapat diprediksi.

Kami telah memperluas fitur petunjuk SQL untuk membantu Anda mengontrol pilihan pengoptimal untuk rencana kueri Anda. Petunjuk ini berlaku untuk kueri yang menggunakan pengoptimalan kueri paralel. Untuk informasi selengkapnya, lihat Petunjuk Aurora MySQL.

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.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Basis data membuat tabel sementara pada disk

Audit Lanjutan dengan Aurora MySQL