Amazon Redshift tidak akan lagi mendukung penggunaan Python UDF setelah 30 Juni 2026. Kami akan mulai menegakkannya secara bertahap. Untuk informasi lebih lanjut tentang detail opsi akhir masa pakai dan migrasi Python, lihat posting blog
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.
Topik
Statistik tabel hilang atau kedaluwarsa
Jika statistik tabel hilang atau kedaluwarsa, Anda mungkin melihat yang berikut:
-
Pesan peringatan dalam hasil perintah EXPLAIN.
-
Peristiwa peringatan statistik yang hilang di STL_ALERT_EVENT_LOG. Untuk informasi selengkapnya, lihat Meninjau peringatan kueri.
Untuk memperbaiki masalah ini, jalankanMENGANALISA.
Loop Bersarang
Jika loop bersarang ada, Anda mungkin melihat peristiwa peringatan loop bersarang di STL_ALERT_EVENT_LOG. Anda juga dapat mengidentifikasi jenis acara ini dengan menjalankan kueri diMengidentifikasi kueri dengan loop bersarang. Untuk informasi selengkapnya, lihat Meninjau peringatan kueri.
Untuk memperbaikinya, tinjau kueri Anda untuk cross-join dan hapus jika memungkinkan. Cross-joins 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.
Gabung hash
Jika hash join hadir, Anda mungkin melihat yang berikut ini:
-
Operasi gabungan hash dan hash dalam rencana kueri. Untuk informasi selengkapnya, lihat Menganalisis rencana kueri.
-
Langkah HJOIN di segmen dengan nilai maxtime tertinggi di SVL_QUERY_SUMMARY. Untuk informasi selengkapnya, lihat Menggunakan tampilan SVL_QUERY_SUMMARY.
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 pengurutan.
-
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 primer, itu meningkatkan jumlah baris yang terlibat dalam gabungan.
Baris hantu atau baris yang tidak diikat
Jika ada baris hantu atau baris yang tidak diikat, Anda mungkin melihat peristiwa peringatan di STL_ALERT_EVENT_LOG yang menunjukkan baris hantu yang berlebihan. Untuk informasi selengkapnya, lihat Meninjau peringatan kueri.
Untuk memperbaiki masalah ini, Anda dapat mengambil beberapa pendekatan:
-
Periksa tab Beban di konsol Amazon Redshift Anda untuk operasi pemuatan aktif pada salah satu tabel kueri. Jika Anda melihat operasi pemuatan aktif, tunggu hingga selesai sebelum mengambil tindakan.
-
Jika tidak ada operasi pemuatan aktif, jalankan VAKUM pada tabel kueri untuk menghapus baris yang dihapus.
Baris yang tidak disortir atau salah disortir
Jika ada baris yang tidak disortir atau salah disortir, Anda mungkin melihat peristiwa peringatan filter yang sangat selektif di STL_ALERT_EVENT_LOG. Untuk informasi selengkapnya, lihat Meninjau peringatan kueri.
Anda juga dapat memeriksa untuk melihat apakah ada tabel dalam kueri Anda yang memiliki area besar yang tidak disortir dengan menjalankan kueri diMengidentifikasi tabel dengan data miring atau baris yang tidak disortir.
Untuk memperbaiki masalah ini, Anda dapat mengambil beberapa pendekatan:
-
Jalan VAKUM kan pada tabel kueri untuk mengurutkan ulang baris.
-
Tinjau kunci pengurutan pada tabel kueri untuk melihat apakah ada perbaikan yang dapat dilakukan. Ingatlah untuk menimbang kinerja kueri ini terhadap kinerja kueri penting lainnya dan sistem secara keseluruhan sebelum membuat perubahan apa pun. Untuk informasi selengkapnya, lihat Urutkan kunci.
Distribusi data yang kurang optimal
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.
-
Irisan tidak memproses kira-kira jumlah baris yang sama untuk langkah tertentu. Untuk informasi selengkapnya, lihat Menggunakan tampilan SVL_QUERY_REPORT.
-
Irisan tidak memakan waktu yang kira-kira sama untuk langkah tertentu. Untuk informasi selengkapnya, lihat Menggunakan tampilan SVL_QUERY_REPORT.
Jika tidak ada yang sebelumnya benar, Anda juga dapat melihat apakah salah satu tabel dalam kueri Anda memiliki kemiringan data dengan menjalankan kueri diMengidentifikasi tabel dengan data miring atau baris yang tidak disortir.
Untuk memperbaiki masalah ini, tinjau gaya distribusi untuk tabel dalam kueri dan lihat apakah ada perbaikan yang dapat dilakukan. Ingatlah untuk menimbang 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.
Memori yang tidak mencukupi yang dialokasikan untuk kueri
Jika memori tidak mencukupi 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.
Untuk memperbaiki masalah ini, alokasikan lebih banyak memori ke kueri dengan meningkatkan sementara jumlah slot kueri yang digunakannya. Manajemen Beban Kerja (WLM) mencadangkan slot dalam antrian kueri yang setara dengan tingkat konkurensi yang ditetapkan untuk antrian. Misalnya, antrian dengan tingkat konkurensi 5 memiliki 5 slot. Memori yang ditetapkan ke antrian dialokasikan secara merata untuk setiap slot. Menetapkan beberapa slot ke satu kueri memberikan akses kueri itu ke memori untuk semua slot tersebut. Untuk informasi selengkapnya tentang cara meningkatkan sementara slot untuk kueri, lihatwlm_query_slot_count.
Klausa WHERE yang tidak optimal
Jika klausa WHERE menyebabkan pemindaian tabel 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.
Untuk memperbaiki masalah ini, tambahkan klausa WHERE ke kueri berdasarkan kolom jenis utama dari tabel terbesar. Pendekatan ini membantu meminimalkan waktu pemindaian. Untuk informasi selengkapnya, lihat Praktik terbaik Amazon Redshift untuk merancang tabel.
Predikat yang tidak cukup membatasi
Jika kueri Anda memiliki predikat terbatas yang tidak cukup, 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 rows dalam kueri. Untuk informasi selengkapnya, lihat Menggunakan tampilan SVL_QUERY_SUMMARY.
Untuk memperbaiki masalah ini, coba tambahkan predikat ke kueri atau membuat predikat yang ada lebih membatasi untuk mempersempit output.
Set hasil yang sangat besar
Jika kueri Anda mengembalikan kumpulan hasil yang sangat besar, pertimbangkan untuk menulis ulang kueri MEMBONGKAR untuk digunakan untuk menulis hasil ke Amazon S3. Pendekatan ini meningkatkan kinerja langkah RETURN dengan mengambil keuntungan dari pemrosesan paralel. Untuk informasi selengkapnya tentang memeriksa kumpulan hasil yang sangat besar, lihatMenggunakan tampilan SVL_QUERY_SUMMARY.
Daftar SELECT besar
Jika kueri Anda memiliki daftar SELECT yang luar biasa besar, Anda mungkin melihat bytes nilai yang relatif tinggi terhadap rows nilai untuk setiap langkah (dibandingkan dengan langkah lain) di SVL_QUERY_SUMMARY. bytesNilai tinggi ini dapat menjadi indikator bahwa Anda memilih banyak kolom. Untuk informasi selengkapnya, lihat Menggunakan tampilan SVL_QUERY_SUMMARY.
Untuk memperbaiki masalah ini, tinjau kolom yang Anda pilih dan lihat apakah ada yang dapat dihapus.
