Amazon Redshift tidak akan lagi mendukung pembuatan Python UDFs baru mulai Patch 198. Python yang ada UDFs akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat [posting blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Analisis dan peningkatan kueri
Mengambil informasi dari gudang data Amazon Redshift melibatkan menjalankan kueri kompleks pada data dalam jumlah yang sangat besar, yang dapat memakan waktu lama untuk diproses. Untuk memastikan bahwa kueri diproses secepat mungkin, ada sejumlah alat yang dapat Anda gunakan untuk mengidentifikasi potensi masalah kinerja.
**Topics**
+ [
# Alur kerja analisis kueri
](c-query-analysis-process.md)
+ [
# Meninjau peringatan kueri
](c-reviewing-query-alerts.md)
+ [
# Menganalisis rencana kueri
](c-analyzing-the-query-plan.md)
+ [
# Menganalisis ringkasan kueri
](c-analyzing-the-query-summary.md)
+ [
# Peningkatan kinerja kueri
](query-performance-improvement-opportunities.md)
+ [
# Kueri diagnostik untuk penyetelan kueri
](diagnostic-queries-for-query-tuning.md)
# Alur kerja analisis kueri
Jika kueri membutuhkan waktu lebih lama dari yang diharapkan, gunakan langkah-langkah berikut untuk mengidentifikasi dan memperbaiki masalah yang mungkin berdampak negatif pada kinerja kueri. Jika Anda tidak yakin kueri apa di sistem Anda yang mungkin mendapat manfaat dari penyetelan kinerja, mulailah dengan menjalankan kueri diagnostik. [Mengidentifikasi kueri yang merupakan kandidat teratas untuk penyetelan](identify-queries-that-are-top-candidates-for-tuning.md)
1. Pastikan tabel Anda dirancang sesuai dengan praktik terbaik. Untuk informasi selengkapnya, lihat [Praktik terbaik Amazon Redshift untuk mendesain tabel](c_designing-tables-best-practices.md).
1. Lihat apakah Anda dapat menghapus atau mengarsipkan data yang tidak dibutuhkan di tabel Anda. Misalnya, kueri Anda selalu menargetkan data senilai 6 bulan terakhir tetapi Anda memiliki nilai 18 bulan terakhir di tabel Anda. Dalam hal ini, Anda dapat menghapus atau mengarsipkan data lama untuk mengurangi jumlah catatan yang harus dipindai dan didistribusikan.
1. Jalankan [VAKUM](r_VACUUM_command.md) perintah pada tabel dalam kueri untuk merebut kembali ruang dan mengurutkan ulang baris. Menjalankan VACUUM membantu jika wilayah yang tidak disortir besar dan kueri menggunakan kunci pengurutan dalam gabungan atau predikat.
1. Jalankan [MENGANALISA](r_ANALYZE.md) perintah pada tabel dalam kueri untuk memastikan bahwa statistik mutakhir. Menjalankan ANALYZE membantu jika salah satu tabel dalam kueri baru-baru ini banyak berubah ukurannya. Jika menjalankan perintah ANALYZE penuh akan memakan waktu terlalu lama, jalankan ANALYZE pada satu kolom untuk mengurangi waktu pemrosesan. Pendekatan ini masih memperbarui statistik ukuran tabel; ukuran tabel merupakan faktor penting dalam perencanaan kueri.
1. Pastikan bahwa kueri Anda telah dijalankan sekali untuk setiap jenis klien (berdasarkan jenis protokol koneksi apa yang digunakan klien) sehingga kueri dikompilasi dan di-cache. Pendekatan ini mempercepat proses kueri berikutnya. Untuk informasi selengkapnya, lihat [Faktor-faktor yang mempengaruhi kinerja kueri](c-query-performance.md).
1. Periksa [STL\$1ALERT\$1EVENT\$1LOG](r_STL_ALERT_EVENT_LOG.md) tabel untuk mengidentifikasi dan memperbaiki kemungkinan masalah dengan kueri Anda. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md).
1. Jalankan [EXPLAIN](r_EXPLAIN.md) perintah untuk mendapatkan paket kueri dan gunakan untuk mengoptimalkan kueri. Untuk informasi selengkapnya, lihat [Menganalisis rencana kueri](c-analyzing-the-query-plan.md).
1. Gunakan [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) dan [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md) tampilan untuk mendapatkan informasi ringkasan dan menggunakannya untuk mengoptimalkan kueri. Untuk informasi selengkapnya, lihat [Menganalisis ringkasan kueri](c-analyzing-the-query-summary.md).
Terkadang kueri yang harus berjalan cepat dipaksa untuk menunggu hingga kueri lain yang berjalan lebih lama selesai. Dalam hal ini, Anda mungkin tidak memiliki apa pun untuk ditingkatkan dalam kueri itu sendiri, tetapi Anda dapat meningkatkan kinerja sistem secara keseluruhan dengan membuat dan menggunakan antrian kueri untuk berbagai jenis kueri. Untuk mendapatkan gambaran tentang waktu tunggu antrian untuk kueri Anda, lihat. [Meninjau waktu tunggu antrian untuk kueri](review-queue-wait-times-for-queries.md) Untuk informasi selengkapnya tentang mengonfigurasi antrian kueri, lihat. [Manajemen beban kerja](cm-c-implementing-workload-management.md)
# Meninjau peringatan kueri
Untuk menggunakan tabel [STL\$1ALERT\$1EVENT\$1LOG](r_STL_ALERT_EVENT_LOG.md) sistem untuk mengidentifikasi dan memperbaiki potensi masalah kinerja dengan kueri Anda, ikuti langkah-langkah berikut:
1. Jalankan berikut ini untuk menentukan ID kueri Anda:
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Periksa teks kueri terpotong di `substring` bidang untuk menentukan `query` nilai mana yang akan dipilih. Jika Anda telah menjalankan kueri lebih dari sekali, gunakan `query` nilai dari baris dengan `elapsed` nilai yang lebih rendah. Itu adalah baris untuk versi yang dikompilasi. Jika Anda telah menjalankan banyak kueri, Anda dapat meningkatkan nilai yang digunakan oleh klausa LIMIT yang digunakan untuk memastikan bahwa kueri Anda disertakan.
1. Pilih baris dari STL\$1ALERT\$1EVENT\$1LOG untuk kueri Anda:
```
Select * from stl_alert_event_log where query = MyQueryID;
```
![\[Contoh hasil kueri dari STL_ALERT_EVENT_LOG.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/stl_alert_event_log_results.png)
1. Evaluasi hasil untuk kueri Anda. Gunakan tabel berikut untuk menemukan solusi potensial untuk masalah apa pun yang telah Anda identifikasi.
**catatan**
Tidak semua kueri memiliki baris di STL\$1ALERT\$1EVENT\$1LOG, hanya yang memiliki masalah yang diidentifikasi.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/c-reviewing-query-alerts.html)
# Menganalisis rencana kueri
Jalankan [EXPLAIN](r_EXPLAIN.md) perintah untuk mendapatkan rencana kueri.
Sebelum menganalisis rencana kueri, Anda harus terbiasa dengan cara membacanya. Jika Anda tidak terbiasa membaca rencana kueri, kami sarankan Anda membaca [Membuat dan menafsirkan rencana kueri](c-the-query-plan.md) sebelum melanjutkan.
Untuk menganalisis data yang disediakan oleh rencana kueri, ikuti langkah-langkah berikut:
1. Identifikasi langkah-langkah dengan biaya tertinggi. Berkonsentrasilah untuk mengoptimalkannya saat melanjutkan langkah-langkah yang tersisa.
1. Lihatlah jenis gabungannya:
+ **Nested Loop**: Gabungan seperti itu biasanya terjadi karena kondisi gabungan dihilangkan. Untuk solusi yang direkomendasikan, lihat[Loop Bersarang](query-performance-improvement-opportunities.md#nested-loop).
+ **Hash dan Hash Join: Gabungan** hash digunakan saat menggabungkan tabel di mana kolom gabungan bukan kunci distribusi dan juga bukan kunci pengurutan. Untuk solusi yang direkomendasikan, lihat[Hash bergabung](query-performance-improvement-opportunities.md#hash-join).
+ **Gabung Gabung**: Tidak diperlukan perubahan.
1. Perhatikan tabel mana yang digunakan untuk penggabungan bagian dalam, dan yang mana untuk gabungan luar. Mesin kueri umumnya memilih tabel yang lebih kecil untuk sambungan bagian dalam, dan tabel yang lebih besar untuk gabungan luar. Jika pilihan seperti itu tidak terjadi, statistik Anda kemungkinan sudah ketinggalan zaman. Untuk solusi yang direkomendasikan, lihat[Statistik tabel hilang atau kedaluwarsa](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date).
1. Lihat apakah ada operasi pengurutan berbiaya tinggi. Jika ada, lihat [Baris yang tidak disortir atau disortir](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows) solusi yang direkomendasikan.
1. Cari operator siaran berikut di mana ada operasi berbiaya tinggi:
+ **DS\$1BCAST\$1INNER**: Menunjukkan bahwa tabel disiarkan ke semua node komputasi. Ini bagus untuk meja kecil, tetapi tidak ideal untuk meja yang lebih besar.
+ **DS\$1DIST\$1ALL\$1INNER**: Menunjukkan bahwa semua beban kerja berada pada satu irisan.
+ **DS\$1DIST\$1BOTH: Menunjukkan redistribusi** berat.
Untuk solusi yang direkomendasikan untuk situasi ini, lihat[Distribusi data suboptimal](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
# Menganalisis ringkasan kueri
Untuk mendapatkan langkah-langkah eksekusi dan statistik secara lebih rinci daripada dalam rencana kueri yang [EXPLAIN](r_EXPLAIN.md) menghasilkan, gunakan tampilan [SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md) dan [SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md) sistem.
SVL\$1QUERY\$1SUMMARY menyediakan statistik kueri berdasarkan aliran. Anda dapat menggunakan informasi yang diberikannya untuk mengidentifikasi masalah dengan langkah-langkah mahal, langkah-langkah yang berjalan lama, dan langkah-langkah yang menulis ke disk.
Tampilan sistem SVL\$1QUERY\$1REPORT memungkinkan Anda melihat informasi yang mirip dengan itu untuk SVL\$1QUERY\$1SUMMARY, hanya dengan menghitung irisan simpul daripada berdasarkan aliran. Anda dapat menggunakan informasi tingkat irisan untuk mendeteksi distribusi data yang tidak merata di seluruh cluster (juga dikenal sebagai kemiringan distribusi data), yang memaksa beberapa node untuk melakukan lebih banyak pekerjaan daripada yang lain dan merusak kinerja kueri.
**Topics**
+ [
# Menggunakan tampilan SVL\$1QUERY\$1SUMMARY
](using-SVL-Query-Summary.md)
+ [
# Menggunakan tampilan SVL\$1QUERY\$1REPORT
](using-SVL-Query-Report.md)
+ [
# Memetakan rencana kueri ke ringkasan kueri
](query-plan-summary-map.md)
# Menggunakan tampilan SVL\$1QUERY\$1SUMMARY
Untuk menganalisis informasi ringkasan kueri dengan streaming menggunakan[SVL\$1QUERY\$1SUMMARY](r_SVL_QUERY_SUMMARY.md), lakukan hal berikut:
1. Jalankan kueri berikut untuk menentukan ID kueri Anda:
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Periksa teks kueri terpotong di `substring` bidang untuk menentukan `query` nilai mana yang mewakili kueri Anda. Jika Anda telah menjalankan kueri lebih dari sekali, gunakan `query` nilai dari baris dengan `elapsed` nilai yang lebih rendah. Itu adalah baris untuk versi yang dikompilasi. Jika Anda telah menjalankan banyak kueri, Anda dapat meningkatkan nilai yang digunakan oleh klausa LIMIT yang digunakan untuk memastikan bahwa kueri Anda disertakan.
1. Pilih baris dari SVL\$1QUERY\$1SUMMARY untuk kueri Anda. Urutkan hasil berdasarkan aliran, segmen, dan langkah:
```
select * from svl_query_summary where query = MyQueryID order by stm, seg, step;
```
Berikut ini adalah contoh hasil.
![\[Hasil sampel untuk baris di SVL_QUERY_SUMMARY yang cocok dengan kueri yang diberikan.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/svl_query_summary_results.png)
1. Petakan langkah-langkah untuk operasi dalam rencana kueri menggunakan informasi di[Memetakan rencana kueri ke ringkasan kueri](query-plan-summary-map.md). Mereka harus memiliki nilai yang kira-kira sama untuk baris dan byte (baris \$1 lebar dari rencana kueri). Jika tidak, lihat solusi [Statistik tabel hilang atau kedaluwarsa](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date) yang direkomendasikan.
1. Lihat apakah `is_diskbased` bidang memiliki nilai `t` (true) untuk setiap langkah. Hash, agregat, dan sortir adalah operator yang cenderung menulis data ke disk jika sistem tidak memiliki cukup memori yang dialokasikan untuk pemrosesan kueri.
Jika `is_diskbased` benar, lihat [Memori tidak cukup dialokasikan untuk kueri](query-performance-improvement-opportunities.md#insufficient-memory-allocated-to-the-query) solusi yang direkomendasikan.
1. Tinjau nilai `label` bidang dan lihat apakah ada AGG-DIST-AGG urutan di mana saja dalam langkah-langkahnya. Kehadirannya menunjukkan agregasi dua langkah, yang mahal. Untuk memperbaikinya, ubah klausa GROUP BY untuk menggunakan kunci distribusi (kunci pertama, jika ada beberapa kunci).
1. Tinjau `maxtime` nilai untuk setiap segmen (sama di semua langkah di segmen). Identifikasi segmen dengan `maxtime` nilai tertinggi dan tinjau langkah-langkah di segmen ini untuk operator berikut.
**catatan**
`maxtime`Nilai tinggi tidak selalu menunjukkan masalah dengan segmen. Meskipun nilainya tinggi, segmen ini mungkin tidak membutuhkan waktu lama untuk diproses. Semua segmen dalam aliran mulai diatur waktunya secara serempak. Namun, beberapa segmen hilir mungkin tidak dapat berjalan sampai mereka mendapatkan data dari segmen hulu. Efek ini mungkin membuat mereka tampak memakan waktu lama karena `maxtime` nilainya mencakup waktu tunggu dan waktu pemrosesan mereka.
+ **BCAST atau DIST**: Dalam kasus ini, `maxtime` nilai tinggi mungkin merupakan hasil dari mendistribusikan kembali sejumlah besar baris. Untuk solusi yang direkomendasikan, lihat[Distribusi data suboptimal](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
+ **HJOIN (hash join)**: Jika langkah yang dimaksud memiliki nilai yang sangat tinggi di `rows` bidang dibandingkan dengan `rows` nilai pada langkah RETURN terakhir dalam kueri, lihat solusi yang [Hash bergabung](query-performance-improvement-opportunities.md#hash-join) direkomendasikan.
+ **SCAN/SORT**: Cari urutan langkah SCAN, SORT, SCAN, MERGE tepat sebelum langkah bergabung. Pola ini menunjukkan bahwa data yang tidak disortir sedang dipindai, diurutkan, dan kemudian digabungkan dengan area tabel yang diurutkan.
Lihat apakah nilai baris untuk langkah SCAN memiliki nilai yang sangat tinggi dibandingkan dengan nilai baris pada langkah RETURN terakhir dalam kueri. Pola ini menunjukkan bahwa mesin eksekusi memindai baris yang kemudian dibuang, yang tidak efisien. Untuk solusi yang direkomendasikan, lihat[Predikat yang tidak cukup membatasi](query-performance-improvement-opportunities.md#insufficiently-restrictive-predicate).
Jika `maxtime` nilai untuk langkah SCAN tinggi, lihat solusi yang [Klausa WHERE suboptimal](query-performance-improvement-opportunities.md#suboptimal-WHERE-clause) direkomendasikan.
Jika `rows` nilai untuk langkah SORT bukan nol, lihat solusi yang [Baris yang tidak disortir atau disortir](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows) direkomendasikan.
1. Tinjau `rows` dan `bytes` nilai untuk 5-10 langkah yang mendahului langkah RETURN akhir untuk mendapatkan gambaran tentang jumlah data yang dikembalikan ke klien. Proses ini bisa menjadi sedikit seni.
Misalnya, dalam ringkasan kueri contoh berikut, langkah PROJECT ketiga memberikan `rows` nilai, tetapi bukan `bytes` nilai. Dengan melihat melalui langkah-langkah sebelumnya untuk satu dengan `rows` nilai yang sama, Anda menemukan langkah SCAN yang menyediakan informasi baris dan byte.
Berikut ini adalah hasil sampel.
![\[Baris dalam hasil ringkasan kueri yang merupakan langkah SCAN dengan informasi baris dan byte.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/rows_and_bytes.png)
Jika Anda mengembalikan volume data yang luar biasa besar, lihat solusi yang [Set hasil yang sangat besar](query-performance-improvement-opportunities.md#very-large-result-set) direkomendasikan.
1. Lihat apakah `bytes` nilainya relatif tinggi terhadap `rows` nilai untuk langkah apa pun, dibandingkan dengan langkah lain. Pola ini dapat menunjukkan bahwa Anda memilih banyak kolom. Untuk solusi yang direkomendasikan, lihat[Daftar SELECT besar](query-performance-improvement-opportunities.md#large-SELECT-list).
# Menggunakan tampilan SVL\$1QUERY\$1REPORT
Untuk menganalisis informasi ringkasan kueri dengan menggunakan slice[SVL\$1QUERY\$1REPORT](r_SVL_QUERY_REPORT.md), lakukan hal berikut:
1. Jalankan berikut ini untuk menentukan ID kueri Anda:
```
select query, elapsed, substring
from svl_qlog
order by query
desc limit 5;
```
Periksa teks kueri terpotong di `substring` bidang untuk menentukan `query` nilai mana yang mewakili kueri Anda. Jika Anda telah menjalankan kueri lebih dari sekali, gunakan `query` nilai dari baris dengan `elapsed` nilai yang lebih rendah. Itu adalah baris untuk versi yang dikompilasi. Jika Anda telah menjalankan banyak kueri, Anda dapat meningkatkan nilai yang digunakan oleh klausa LIMIT yang digunakan untuk memastikan bahwa kueri Anda disertakan.
1. Pilih baris dari SVL\$1QUERY\$1REPORT untuk kueri Anda. Urutkan hasil berdasarkan segmen, langkah, elapsed\$1time, dan baris:
```
select * from svl_query_report where query = MyQueryID order by segment, step, elapsed_time, rows;
```
1. Untuk setiap langkah, periksa untuk melihat bahwa semua irisan memproses kira-kira jumlah baris yang sama:
![\[Sebuah daftar irisan data yang digunakan untuk menjalankan query. Setiap irisan memproses kira-kira jumlah baris yang sama.\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/SVL_QUERY_REPORT_rows.png)
Periksa juga untuk melihat bahwa semua irisan membutuhkan waktu yang kira-kira sama:
![\[Sebuah daftar irisan data yang digunakan untuk menjalankan query. Setiap irisan membutuhkan waktu yang kira-kira sama..\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/images/SVL_QUERY_REPORT_elapsed_time.png)
Perbedaan besar dalam nilai-nilai ini dapat menunjukkan kemiringan distribusi data karena gaya distribusi suboptimal untuk kueri khusus ini. Untuk solusi yang direkomendasikan, lihat[Distribusi data suboptimal](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
# Memetakan rencana kueri ke ringkasan kueri
Saat menganalisis ringkasan kueri, Anda bisa mendapatkan detail lebih lanjut dengan memetakan operasi dari rencana kueri ke langkah-langkah (diidentifikasi oleh nilai bidang label) dalam ringkasan kueri. Tabel berikut memetakan operasi rencana kueri ke langkah-langkah ringkasan kueri.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/query-plan-summary-map.html)
# Peningkatan kinerja kueri
Berikut ini adalah beberapa masalah umum yang memengaruhi kinerja kueri Amazon Redshift, dengan petunjuk tentang cara mendiagnosis dan menyelesaikannya.
**Topics**
+ [
## Statistik tabel hilang atau kedaluwarsa
](#table-statistics-missing-or-out-of-date)
+ [
## Loop Bersarang
](#nested-loop)
+ [
## Hash bergabung
](#hash-join)
+ [
## Baris hantu atau baris yang tidak terikat
](#ghost-rows-or-uncommitted-rows)
+ [
## Baris yang tidak disortir atau disortir
](#unsorted-or-mis-sorted-rows)
+ [
## Distribusi data suboptimal
](#suboptimal-data-distribution)
+ [
## Memori tidak cukup dialokasikan untuk kueri
](#insufficient-memory-allocated-to-the-query)
+ [
## Klausa WHERE suboptimal
](#suboptimal-WHERE-clause)
+ [
## Predikat yang tidak cukup membatasi
](#insufficiently-restrictive-predicate)
+ [
## Set hasil yang sangat besar
](#very-large-result-set)
+ [
## Daftar SELECT besar
](#large-SELECT-list)
## Statistik tabel hilang atau kedaluwarsa
Jika statistik tabel hilang atau kedaluwarsa, Anda mungkin melihat yang berikut:
+ Pesan peringatan dalam hasil perintah EXPLORE.
+ Peristiwa peringatan statistik yang hilang di STL\$1ALERT\$1EVENT\$1LOG. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md).
Untuk memperbaiki masalah ini, jalankan[MENGANALISA](r_ANALYZE.md).
## Loop Bersarang
Jika loop bersarang hadir, Anda mungkin melihat peristiwa peringatan loop bersarang di STL\$1ALERT\$1EVENT\$1LOG. Anda juga dapat mengidentifikasi jenis acara ini dengan menjalankan kueri di[Mengidentifikasi kueri dengan loop bersarang](identify-queries-with-nested-loops.md). Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md).
Untuk memperbaikinya, tinjau kueri Anda untuk cross-join dan hapus jika memungkinkan. Cross-join adalah gabungan tanpa kondisi gabungan yang menghasilkan produk Cartesian dari dua tabel. Mereka biasanya dijalankan sebagai gabungan loop bersarang, yang merupakan jenis gabungan yang paling lambat.
## Hash bergabung
Jika bergabung dengan hash hadir, Anda mungkin melihat yang berikut ini:
+ Hash dan hash bergabung dengan operasi dalam rencana kueri. Untuk informasi selengkapnya, lihat [Menganalisis rencana kueri](c-analyzing-the-query-plan.md).
+ Langkah HJOIN di segmen dengan nilai maxtime tertinggi di SVL\$1QUERY\$1SUMMARY. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Untuk memperbaiki masalah ini, Anda dapat mengambil beberapa pendekatan:
+ Tulis ulang kueri untuk menggunakan gabungan gabungan jika memungkinkan. Anda dapat melakukan ini dengan menentukan kolom gabungan yang merupakan kunci distribusi dan kunci sortir.
+ Jika langkah HJOIN di SVL\$1QUERY\$1SUMMARY memiliki nilai yang sangat tinggi di bidang baris dibandingkan dengan nilai baris pada langkah RETURN terakhir dalam kueri, periksa apakah Anda dapat menulis ulang kueri untuk bergabung pada kolom unik. Ketika kueri tidak bergabung pada kolom unik, seperti kunci utama, itu meningkatkan jumlah baris yang terlibat dalam gabungan.
## Baris hantu atau baris yang tidak terikat
Jika ada baris hantu atau baris yang tidak terikat, Anda mungkin melihat peristiwa peringatan di STL\$1ALERT\$1EVENT\$1LOG yang menunjukkan baris hantu yang berlebihan. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md).
Untuk memperbaiki masalah ini, Anda dapat mengambil beberapa pendekatan:
+ **Periksa tab Memuat konsol Amazon Redshift Anda untuk operasi pemuatan aktif di salah satu tabel kueri.** Jika Anda melihat operasi beban aktif, tunggu sampai selesai sebelum mengambil tindakan.
+ Jika tidak ada operasi pemuatan aktif, jalankan [VAKUM](r_VACUUM_command.md) pada tabel kueri untuk menghapus baris yang dihapus.
## Baris yang tidak disortir atau disortir
Jika ada baris yang tidak disortir atau disortir, Anda mungkin melihat peristiwa peringatan filter yang sangat selektif di STL\$1ALERT\$1EVENT\$1LOG. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md).
Anda juga dapat memeriksa untuk melihat apakah ada tabel dalam kueri Anda memiliki area besar yang tidak disortir dengan menjalankan kueri di. [Mengidentifikasi tabel dengan data miring atau baris yang tidak disortir](identify-tables-with-data-skew-or-unsorted-rows.md)
Untuk memperbaiki masalah ini, Anda dapat mengambil beberapa pendekatan:
+ Jalankan [VAKUM](r_VACUUM_command.md) pada tabel kueri untuk mengurutkan ulang baris.
+ Tinjau kunci pengurutan pada tabel kueri untuk melihat apakah ada perbaikan yang dapat dilakukan. Ingatlah untuk mempertimbangkan kinerja kueri ini terhadap kinerja kueri penting lainnya dan sistem secara keseluruhan sebelum membuat perubahan apa pun. Untuk informasi selengkapnya, lihat [Sortir kunci](t_Sorting_data.md).
## Distribusi data suboptimal
Jika distribusi data kurang optimal, Anda mungkin melihat yang berikut:
+ Eksekusi serial, siaran besar, atau peristiwa peringatan distribusi besar muncul di STL\$1ALERT\$1EVENT\$1LOG. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md).
+ Irisan tidak memproses kira-kira jumlah baris yang sama untuk langkah tertentu. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1REPORT](using-SVL-Query-Report.md).
+ Irisan tidak mengambil kira-kira jumlah waktu yang sama untuk langkah tertentu. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1REPORT](using-SVL-Query-Report.md).
Jika tidak ada yang sebelumnya benar, Anda juga dapat melihat apakah salah satu tabel dalam kueri Anda memiliki kemiringan data dengan menjalankan kueri di. [Mengidentifikasi tabel dengan data miring atau baris yang tidak disortir](identify-tables-with-data-skew-or-unsorted-rows.md)
Untuk memperbaiki masalah ini, tinjau gaya distribusi untuk tabel dalam kueri dan lihat apakah ada perbaikan yang dapat dilakukan. Ingatlah untuk mempertimbangkan kinerja kueri ini terhadap kinerja kueri penting lainnya dan sistem secara keseluruhan sebelum membuat perubahan apa pun. Untuk informasi selengkapnya, lihat [Distribusi data untuk optimasi kueri](t_Distributing_data.md).
## Memori tidak cukup dialokasikan untuk kueri
Jika memori tidak cukup dialokasikan untuk kueri Anda, Anda mungkin melihat langkah di SVL\$1QUERY\$1SUMMARY yang memiliki nilai true. `is_diskbased` Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Untuk memperbaiki masalah ini, alokasikan lebih banyak memori ke kueri dengan meningkatkan sementara jumlah slot kueri yang digunakannya. Manajemen Beban Kerja (WLM) menyimpan slot dalam antrian kueri yang setara dengan tingkat konkurensi yang ditetapkan untuk antrian. Misalnya, antrian dengan level konkurensi 5 memiliki 5 slot. Memori yang ditugaskan ke antrian dialokasikan secara merata ke setiap slot. Menetapkan beberapa slot ke satu kueri memberikan akses kueri ke memori untuk semua slot tersebut. Untuk informasi lebih lanjut tentang cara meningkatkan slot sementara untuk kueri, lihat[wlm\$1query\$1slot\$1count](r_wlm_query_slot_count.md).
## Klausa WHERE suboptimal
Jika klausa WHERE menyebabkan pemindaian tabel yang berlebihan, Anda mungkin melihat langkah SCAN di segmen dengan `maxtime` nilai tertinggi di SVL\$1QUERY\$1SUMMARY. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Untuk memperbaiki masalah ini, tambahkan klausa WHERE ke kueri berdasarkan kolom pengurutan utama tabel terbesar. Pendekatan ini membantu meminimalkan waktu pemindaian. Untuk informasi selengkapnya, lihat [Praktik terbaik Amazon Redshift untuk mendesain tabel](c_designing-tables-best-practices.md).
## Predikat yang tidak cukup membatasi
Jika kueri Anda memiliki predikat restriktif yang tidak memadai, Anda mungkin melihat langkah SCAN di segmen dengan `maxtime` nilai tertinggi di SVL\$1QUERY\$1SUMMARY yang memiliki nilai sangat tinggi dibandingkan dengan `rows` nilai pada langkah RETURN terakhir dalam `rows` kueri. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Untuk memperbaiki masalah ini, coba tambahkan predikat ke kueri atau buat predikat yang ada lebih ketat untuk mempersempit output.
## Set hasil yang sangat besar
Jika kueri Anda mengembalikan kumpulan hasil yang sangat besar, pertimbangkan untuk menulis ulang kueri yang akan digunakan [MEMBONGKAR](r_UNLOAD.md) untuk menulis hasil ke Amazon S3. Pendekatan ini meningkatkan kinerja langkah RETURN dengan memanfaatkan pemrosesan paralel. Untuk informasi lebih lanjut tentang memeriksa set hasil yang sangat besar, lihat[Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
## Daftar SELECT besar
Jika kueri Anda memiliki daftar SELECT yang luar biasa besar, Anda mungkin melihat `bytes` nilai yang relatif tinggi terhadap nilai untuk langkah apa pun (dibandingkan dengan `rows` langkah lain) di SVL\$1QUERY\$1SUMMARY. `bytes`Nilai tinggi ini bisa menjadi indikator bahwa Anda memilih banyak kolom. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\$1QUERY\$1SUMMARY](using-SVL-Query-Summary.md).
Untuk memperbaiki masalah ini, tinjau kolom yang Anda pilih dan lihat apakah ada yang dapat dihapus.
# Kueri diagnostik untuk penyetelan kueri
Gunakan kueri berikut untuk mengidentifikasi masalah dengan kueri atau tabel dasar yang dapat memengaruhi kinerja kueri. Sebaiknya gunakan kueri ini dengan proses penyetelan kueri yang dibahas di. [Analisis dan peningkatan kueri](c-query-tuning.md)
**catatan**
Kueri ini untuk kluster yang disediakan Amazon Redshift. Kueri ini tidak untuk digunakan dengan grup kerja Redshift Serverless.
**Topics**
+ [
# Mengidentifikasi kueri yang merupakan kandidat teratas untuk penyetelan
](identify-queries-that-are-top-candidates-for-tuning.md)
+ [
# Mengidentifikasi tabel dengan data miring atau baris yang tidak disortir
](identify-tables-with-data-skew-or-unsorted-rows.md)
+ [
# Mengidentifikasi kueri dengan loop bersarang
](identify-queries-with-nested-loops.md)
+ [
# Meninjau waktu tunggu antrian untuk kueri
](review-queue-wait-times-for-queries.md)
+ [
# Meninjau peringatan kueri berdasarkan tabel
](review-query-alerts-by-table.md)
+ [
# Mengidentifikasi tabel dengan statistik yang hilang
](identify-tables-with-missing-statistics.md)
# Mengidentifikasi kueri yang merupakan kandidat teratas untuk penyetelan
Kueri berikut mengidentifikasi 50 pernyataan paling memakan waktu teratas yang telah dijalankan dalam 7 hari terakhir. Anda dapat menggunakan hasilnya untuk mengidentifikasi kueri yang membutuhkan waktu yang sangat lama. Anda juga dapat mengidentifikasi kueri yang sering dijalankan (kueri yang muncul lebih dari sekali dalam kumpulan hasil). Kueri ini seringkali merupakan kandidat yang baik untuk penyetelan guna meningkatkan kinerja sistem.
Kueri ini juga menyediakan hitungan peristiwa peringatan yang terkait dengan setiap kueri yang diidentifikasi. Peringatan ini memberikan detail yang dapat Anda gunakan untuk meningkatkan kinerja kueri. Untuk informasi selengkapnya, lihat [Meninjau peringatan kueri](c-reviewing-query-alerts.md).
```
select trim(database) as db, count(query) as n_qry,
max(substring (qrytext,1,80)) as qrytext,
min(run_minutes) as "min" ,
max(run_minutes) as "max",
avg(run_minutes) as "avg", sum(run_minutes) as total,
max(query) as max_query_id,
max(starttime)::date as last_run,
sum(alerts) as alerts, aborted
from (select userid, label, stl_query.query,
trim(database) as database,
trim(querytxt) as qrytext,
md5(trim(querytxt)) as qry_md5,
starttime, endtime,
(datediff(seconds, starttime,endtime)::numeric(12,2))/60 as run_minutes,
alrt.num_events as alerts, aborted
from stl_query
left outer join
(select query, 1 as num_events from stl_alert_event_log group by query ) as alrt
on alrt.query = stl_query.query
where userid <> 1 and starttime >= dateadd(day, -7, current_date))
group by database, label, qry_md5, aborted
order by total desc limit 50;
```
# Mengidentifikasi tabel dengan data miring atau baris yang tidak disortir
Kueri berikut mengidentifikasi tabel yang memiliki distribusi data yang tidak merata (data miring) atau persentase tinggi baris yang tidak disortir.
`skew`Nilai rendah menunjukkan bahwa data tabel didistribusikan dengan benar. Jika tabel memiliki `skew` nilai 4,00 atau lebih tinggi, pertimbangkan untuk memodifikasi gaya distribusi datanya. Untuk informasi selengkapnya, lihat [Distribusi data suboptimal](query-performance-improvement-opportunities.md#suboptimal-data-distribution).
Jika tabel memiliki `pct_unsorted` nilai lebih besar dari 20 persen, pertimbangkan untuk menjalankan [VAKUM](r_VACUUM_command.md) perintah. Untuk informasi selengkapnya, lihat [Baris yang tidak disortir atau disortir](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows).
Juga tinjau `mbytes` dan `pct_of_total` nilai untuk setiap tabel. Kolom ini mengidentifikasi ukuran tabel dan berapa persentase ruang disk mentah yang dikonsumsi tabel. Ruang disk mentah mencakup ruang yang dicadangkan oleh Amazon Redshift untuk penggunaan internal, sehingga lebih besar dari kapasitas disk nominal, yang merupakan jumlah ruang disk yang tersedia untuk pengguna. Gunakan informasi ini untuk memverifikasi bahwa Anda memiliki ruang disk kosong sama dengan setidaknya 2,5 kali ukuran tabel terbesar Anda. Memiliki ruang ini memungkinkan sistem untuk menulis hasil perantara ke disk saat memproses kueri kompleks.
```
select trim(pgn.nspname) as schema,
trim(a.name) as table, id as tableid,
decode(pgc.reldiststyle,0, 'even',1,det.distkey ,8,'all') as distkey, dist_ratio.ratio::decimal(10,4) as skew,
det.head_sort as "sortkey",
det.n_sortkeys as "#sks", b.mbytes,
decode(b.mbytes,0,0,((b.mbytes/part.total::decimal)*100)::decimal(5,2)) as pct_of_total,
decode(det.max_enc,0,'n','y') as enc, a.rows,
decode( det.n_sortkeys, 0, null, a.unsorted_rows ) as unsorted_rows ,
decode( det.n_sortkeys, 0, null, decode( a.rows,0,0, (a.unsorted_rows::decimal(32)/a.rows)*100) )::decimal(5,2) as pct_unsorted
from (select db_id, id, name, sum(rows) as rows,
sum(rows)-sum(sorted_rows) as unsorted_rows
from stv_tbl_perm a
group by db_id, id, name) as a
join pg_class as pgc on pgc.oid = a.id
join pg_namespace as pgn on pgn.oid = pgc.relnamespace
left outer join (select tbl, count(*) as mbytes
from stv_blocklist group by tbl) b on a.id=b.tbl
inner join (select attrelid,
min(case attisdistkey when 't' then attname else null end) as "distkey",
min(case attsortkeyord when 1 then attname else null end ) as head_sort ,
max(attsortkeyord) as n_sortkeys,
max(attencodingtype) as max_enc
from pg_attribute group by 1) as det
on det.attrelid = a.id
inner join ( select tbl, max(mbytes)::decimal(32)/min(mbytes) as ratio
from (select tbl, trim(name) as name, slice, count(*) as mbytes
from svv_diskusage group by tbl, name, slice )
group by tbl, name ) as dist_ratio on a.id = dist_ratio.tbl
join ( select sum(capacity) as total
from stv_partitions where part_begin=0 ) as part on 1=1
where mbytes is not null
order by mbytes desc;
```
# Mengidentifikasi kueri dengan loop bersarang
Kueri berikut mengidentifikasi kueri yang memiliki peristiwa peringatan dicatat untuk loop bersarang. Untuk informasi tentang cara memperbaiki kondisi loop bersarang, lihat[Loop Bersarang](query-performance-improvement-opportunities.md#nested-loop).
```
select query, trim(querytxt) as SQL, starttime
from stl_query
where query in (
select distinct query
from stl_alert_event_log
where event like 'Nested Loop Join in the query plan%')
order by starttime desc;
```
# Meninjau waktu tunggu antrian untuk kueri
Kueri berikut menunjukkan berapa lama kueri terbaru menunggu slot terbuka dalam antrian kueri sebelum dijalankan. Jika Anda melihat tren waktu tunggu yang tinggi, Anda mungkin ingin mengubah konfigurasi antrian kueri Anda untuk throughput yang lebih baik. Untuk informasi selengkapnya, lihat [Menerapkan manual WLM](cm-c-defining-query-queues.md).
```
select trim(database) as DB , w.query,
substring(q.querytxt, 1, 100) as querytxt, w.queue_start_time,
w.service_class as class, w.slot_count as slots,
w.total_queue_time/1000000 as queue_seconds,
w.total_exec_time/1000000 exec_seconds, (w.total_queue_time+w.total_Exec_time)/1000000 as total_seconds
from stl_wlm_query w
left join stl_query q on q.query = w.query and q.userid = w.userid
where w.queue_start_Time >= dateadd(day, -7, current_Date)
and w.total_queue_Time > 0 and w.userid >1
and q.starttime >= dateadd(day, -7, current_Date)
order by w.total_queue_time desc, w.queue_start_time desc limit 35;
```
# Meninjau peringatan kueri berdasarkan tabel
Kueri berikut mengidentifikasi tabel yang memiliki peristiwa peringatan yang dicatat untuk mereka, dan juga mengidentifikasi jenis peringatan apa yang paling sering muncul.
Jika `minutes` nilai untuk baris dengan tabel yang diidentifikasi tinggi, periksa tabel tersebut untuk melihat apakah perlu pemeliharaan rutin, seperti memiliki [MENGANALISA](r_ANALYZE.md) atau [VAKUM](r_VACUUM_command.md) menjalankannya.
Jika `count` nilainya tinggi untuk sebuah baris tetapi `table` nilainya nol, jalankan kueri terhadap STL\$1ALERT\$1EVENT\$1LOG untuk `event` nilai terkait guna menyelidiki mengapa peringatan itu sering muncul.
```
select trim(s.perm_table_name) as table,
(sum(abs(datediff(seconds, s.starttime, s.endtime)))/60)::numeric(24,0) as minutes, trim(split_part(l.event,':',1)) as event, trim(l.solution) as solution,
max(l.query) as sample_query, count(*)
from stl_alert_event_log as l
left join stl_scan as s on s.query = l.query and s.slice = l.slice
and s.segment = l.segment and s.step = l.step
where l.event_time >= dateadd(day, -7, current_Date)
group by 1,3,4
order by 2 desc,6 desc;
```
# Mengidentifikasi tabel dengan statistik yang hilang
Kueri berikut memberikan hitungan kueri yang Anda jalankan terhadap tabel yang tidak memiliki statistik. Jika query ini mengembalikan baris apapun, melihat `plannode` nilai untuk menentukan tabel terpengaruh, dan kemudian berjalan [MENGANALISA](r_ANALYZE.md) di atasnya.
```
select substring(trim(plannode),1,100) as plannode, count(*)
from stl_explain
where plannode like '%missing statistics%'
group by plannode
order by 2 desc;
```