Database Autonomy Service:Slow query log

Prasyarat

Engine database adalah PolarDB for MySQL.

Prosedur

1. Masuk ke Konsol DAS.

2. Di panel navigasi sebelah kiri, klik Intelligent O&M Center > Instance Monitoring.

3. Temukan instans target dan klik ID instans untuk membuka halaman detail instans.

4. Di panel navigasi sebelah kiri, klik Request Analysis > Slow Logs.

5. Di tab Slow Log Analysis, pilih rentang waktu untuk melihat Slow Log Trend, Event Distribution, Slow Log Statistics, dan Slow Log Details.

   • Pada grafik Slow Log Trend, Anda dapat memilih titik waktu tertentu untuk melihat Slow Log Statistics dan Slow Log Details pada waktu tersebut.

     Catatan

     Jika pernyataan SQL lambat terlalu panjang sehingga tidak ditampilkan secara utuh, arahkan penunjuk tetikus ke pernyataan tersebut untuk melihat pernyataan SQL lengkap dalam kotak pop-up.

   • Di area Event Distribution, Anda dapat mencari event log lambat dalam rentang waktu tertentu. Klik suatu event untuk melihat detailnya.

   • Dari daftar drop-down Node ID, Anda dapat melihat jumlah permintaan lambat untuk setiap node.

   • Di tab Slow Query Log Statistics dan Slow Query Log Details, Anda dapat mengklik untuk menyimpan informasi slow query log ke komputer Anda.

   • Anda dapat mengklik untuk membuka konsol OpenAPI Explorer. Parameter yang saat ini dipilih dan dimasukkan akan dibawa secara otomatis untuk debugging API.

   • Di area Slow Log Statistics:

     • Di atas daftar, Anda dapat memilih kondisi filter untuk menyaring data. Kondisi filter yang tersedia bervariasi tergantung pada engine database.

     • Klik ID data di kolom Query ID pada templat SQL target untuk melihat korelasi dan daftar detail yang mencakup distribusi pengguna, distribusi klien, dan tren metrik.

     • Di kolom Actions pada templat SQL target, klik Optimize. Di kotak dialog SQL Diagnostic Optimization yang muncul, lihat hasil diagnosis SQL.

       Jika Anda menerima saran diagnosis, klik Copy di pojok kanan atas halaman dan tempel pernyataan SQL yang telah dioptimalkan ke klien database atau DMS Anda untuk dieksekusi. Jika Anda tidak menerima saran tersebut, klik Cancel untuk mengakhiri diagnosis.

       Catatan

       DAS melakukan diagnosis SQL berdasarkan kompleksitas pernyataan SQL, volume data tabel terkait, dan muatan database. Saran diagnosis mungkin memerlukan waktu lebih dari 20 detik untuk dikembalikan. Setelah diagnosis selesai, mesin diagnostik menyediakan hasil diagnosis, saran optimalisasi, dan manfaat optimalisasi yang diharapkan. Anda dapat memutuskan apakah akan menerima saran tersebut berdasarkan hasil diagnosis.

     • Di kolom Actions pada templat SQL target, klik Throttling. Di halaman SQL Throttling, konfigurasikan parameter pembatasan untuk menerapkan rate limiting pada pernyataan SQL target. Untuk informasi selengkapnya, lihat SQL throttling.

     • Untuk instans database PolarDB for MySQL, di kolom Actions pada templat SQL target, klik IMCI untuk melihat dokumentasi tentang In-Memory Column Index (IMCI).

       Catatan

       • Tombol IMCI ditampilkan jika instans database PolarDB for MySQL tidak memiliki node In-Memory Column Index, Max Execution Time dari slow query log melebihi 20 detik, dan Max Scanned Rows melebihi 200.000.

       • Untuk kueri kompleks dengan volume data besar, Anda dapat menggunakan In-Memory Column Index (IMCI) untuk meningkatkan kinerja kueri.

   • Di area Slow Log Details, Anda juga dapat mengklik Optimize dan Throttling di kolom Actions untuk pernyataan SQL target guna melakukan SQL Diagnostic Optimization dan SQL Throttling.

FAQ

• Q: Mengapa saya tidak melihat data slow query log apa pun?

  A: Statistik slow query log diagregasi menggunakan jendela komputasi real-time, sehingga data terbaru muncul dengan penundaan sekitar 3 menit. Periksa juga hal-hal berikut:

  • Fitur slow query log diaktifkan untuk instans database dan ambang batasnya diatur ke nilai yang wajar.

  • Slow query log benar-benar dihasilkan dalam rentang waktu yang dipilih.

  • Akun saat ini memiliki izin akses DAS untuk instans target.

• Q: Mengapa beberapa instans disorot dengan warna kuning?

  A: Sorotan kuning menunjukkan bahwa RAM user tidak memiliki izin akses data untuk instans tersebut. Anda dapat mengatasi masalah ini dengan salah satu cara berikut:

  • Hubungi administrator untuk memberikan izin akses instans kepada RAM user.

  • Berikan izin Global Group: Kami menyarankan agar Anda memberikan izin DASGlobalGroupAdmin sehingga RAM user dapat membuat grup pengguna sesuai kebutuhan dan melihat data untuk semua instans yang dapat diaksesnya.

• Q: Mengapa slow query log menampilkan Rows_sent sebagai 0 meskipun kueri mengembalikan data?

  A: Hal ini biasanya terjadi ketika aplikasi menggunakan mode Server-side Cursor. Dalam mode Cursor, satu pernyataan SQL dieksekusi dalam dua fase terpisah:

  • Fase EXECUTE: Server mengeksekusi kueri dan menghasilkan set hasil tetapi tidak langsung mengirim baris data ke klien. Hanya metadata seperti definisi kolom yang dikembalikan.

  • Fase FETCH: Klien mengambil baris data secara batch dengan mengeluarkan perintah FETCH.

  Slow query log hanya mencatat statistik untuk fase EXECUTE. Selama fase ini, MySQL telah memindai data (sehingga Rows_examined tidak nol), tetapi belum ada baris yang dikirim ke klien karena baris dikirimkan selama fase FETCH berikutnya. Oleh karena itu, Rows_sent dicatat sebagai 0.

  Skenario umum yang memicu perilaku ini:

  • Java/JDBC: URL koneksi menyertakan useCursorFetch=true, dan PreparedStatement.setFetchSize() diatur ke nilai lebih besar dari 0 atau Integer.MIN_VALUE.

  • Python: Aplikasi menggunakan MySQLdb.cursors.SSCursor atau pymysql.cursors.SSCursor.

  • Framework ORM: Beberapa framework ORM secara default menggunakan kueri streaming untuk set hasil besar. Kueri streaming menggunakan mode Cursor di balik layar.

  Untuk memastikan apakah ini penyebabnya, periksa apakah kode aplikasi Anda mengonfigurasi fetchSize atau menggunakan cursor streaming. Anda juga dapat menjalankan SHOW GLOBAL STATUS LIKE 'Com_stmt_fetch'; pada database untuk memverifikasi apakah permintaan FETCH sedang dikeluarkan.

• Q: Mengapa waktu penyelesaian eksekusi yang tercatat dalam slow query log berbeda dengan waktu eksekusi aktual pernyataan SQL?

  A: Hal ini biasanya terjadi ketika pernyataan SQL yang dieksekusi mengubah zona waktu. Cap waktu dalam slow query log dapat didasarkan pada zona waktu di tingkat sesi, tingkat database, atau tingkat sistem. Log menggunakan zona waktu yang diatur di tingkat database, atau kembali ke zona waktu tingkat sistem jika tidak diatur. Jika pernyataan SQL mengubah zona waktu di tingkat sesi, cap waktu dalam log mungkin tidak dikonversi dengan benar, sehingga menyebabkan perbedaan.

Dokumentasi Terkait

Anda dapat mengaktifkan fitur otonomi DAS untuk secara otomatis mengoptimalkan kueri SQL lambat pada instans database Anda.

• Automatic SQL Optimization

• Automatic SQL Throttling