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.
# 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\_ALERT\_EVENT\_LOG. 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\_ALERT\_EVENT\_LOG. 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\_QUERY\_SUMMARY. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\_QUERY\_SUMMARY](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\_QUERY\_SUMMARY 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\_ALERT\_EVENT\_LOG 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\_ALERT\_EVENT\_LOG. 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\_ALERT\_EVENT\_LOG. 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\_QUERY\_REPORT](using-SVL-Query-Report.md).
+ Irisan tidak mengambil kira-kira jumlah waktu yang sama untuk langkah tertentu. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\_QUERY\_REPORT](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\_QUERY\_SUMMARY yang memiliki nilai true. `is_diskbased` Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\_QUERY\_SUMMARY](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\_query\_slot\_count](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\_QUERY\_SUMMARY. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\_QUERY\_SUMMARY](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\_QUERY\_SUMMARY yang memiliki nilai sangat tinggi dibandingkan dengan `rows` nilai pada langkah RETURN terakhir dalam `rows` kueri. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\_QUERY\_SUMMARY](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\_QUERY\_SUMMARY](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\_QUERY\_SUMMARY. `bytes`Nilai tinggi ini bisa menjadi indikator bahwa Anda memilih banyak kolom. Untuk informasi selengkapnya, lihat [Menggunakan tampilan SVL\_QUERY\_SUMMARY](using-SVL-Query-Summary.md).
Untuk memperbaiki masalah ini, tinjau kolom yang Anda pilih dan lihat apakah ada yang dapat dihapus.