Statistik kueri

Spanner menyediakan tabel bawaan yang menyimpan banyak statistik untuk kueri dan pernyataan bahasa pengolahan data (DML) yang menggunakan CPU paling banyak, dan semua kueri secara gabungan (termasuk kueri aliran perubahan).

Mengakses statistik kueri

Spanner menyediakan statistik kueri dalam skema SPANNER_SYS. Anda dapat menggunakan cara berikut untuk mengakses data SPANNER_SYS:

• Halaman Spanner Studio database di konsol Google Cloud .

• Perintah gcloud spanner databases execute-sql.

• Dasbor Query Insight.

• Metode executeSql atau executeStreamingSql.

Metode baca tunggal berikut yang disediakan Spanner tidak mendukung SPANNER_SYS:

• Melakukan pembacaan yang kuat dari satu baris atau beberapa baris dalam tabel.
• Melakukan pembacaan basi dari satu baris atau beberapa baris dalam tabel.
• Membaca dari satu baris atau beberapa baris dalam indeks sekunder.

Untuk mengetahui informasi selengkapnya, lihat Metode bacaan tunggal.

Penggunaan CPU yang dikelompokkan menurut kueri

Tabel berikut melacak kueri dengan penggunaan CPU tertinggi selama jangka waktu tertentu:

• SPANNER_SYS.QUERY_STATS_TOP_MINUTE: Kueri selama interval 1 menit
• SPANNER_SYS.QUERY_STATS_TOP_10MINUTE: Kueri selama interval 10 menit
• SPANNER_SYS.QUERY_STATS_TOP_HOUR: Kueri selama interval 1 jam

Tabel ini memiliki properti berikut:

• Setiap tabel berisi data untuk interval waktu yang tidak tumpang-tindih dengan panjang yang ditentukan oleh nama tabel.

• Interval didasarkan pada waktu jam. Interval 1 menit berakhir pada menit ke-1, interval 10 menit berakhir setiap 10 menit dimulai pada jam ke-1, dan interval 1 jam berakhir pada jam ke-1.

  Misalnya, pada pukul 11.59.30, interval terbaru yang tersedia untuk kueri SQL adalah:

  • 1 menit: 11.58.00–11.58.59 AM
  • 10 menit: 11.40.00–11.49.59 AM
  • 1 jam: 10.00.00–10.59.59

• Spanner mengelompokkan statistik berdasarkan teks kueri SQL. Jika kueri menggunakan parameter kueri, Spanner akan mengelompokkan semua eksekusi kueri tersebut ke dalam satu baris. Jika kueri menggunakan literal string, Spanner hanya mengelompokkan statistik jika teks kueri lengkapnya identik; jika ada teks yang berbeda, setiap kueri akan muncul sebagai baris terpisah. Untuk DML batch, Spanner menormalisasi batch dengan menghapus duplikat pernyataan identik berturut-turut sebelum membuat sidik jari.

• Jika ada tag permintaan, FPRINT adalah hash tag permintaan. Jika tidak, nilai tersebut adalah hash dari nilai TEXT. Untuk DML yang dipartisi, FPRINT selalu berupa hash dari nilai TEXT.

• Setiap baris berisi statistik untuk semua eksekusi kueri SQL tertentu yang statistiknya diambil oleh Spanner selama interval yang ditentukan.

• Jika Spanner tidak dapat menyimpan semua kueri yang dijalankan selama interval, sistem akan memprioritaskan kueri dengan penggunaan CPU tertinggi selama interval yang ditentukan.

• Kueri yang dilacak mencakup kueri yang selesai, gagal, atau dibatalkan oleh pengguna.

• Sebagian statistik khusus untuk kueri yang berjalan tetapi tidak selesai:

  • Jumlah eksekusi dan latensi rata-rata dalam detik di semua kueri yang tidak berhasil.

  • Jumlah eksekusi untuk kueri yang waktunya habis.

  • Jumlah eksekusi untuk kueri yang dibatalkan oleh pengguna atau gagal karena masalah konektivitas jaringan.

• Semua kolom dalam tabel dapat bernilai null.

Statistik kueri untuk pernyataan DML terpartisi yang dijalankan sebelumnya memiliki properti berikut:

• Setiap pernyataan DML terpartisi yang berhasil dihitung secara ketat sebagai satu eksekusi. Pernyataan DML yang dipartisi yang gagal, dibatalkan, atau sedang dieksekusi memiliki jumlah eksekusi nol.

• Statistik ALL_FAILED_EXECUTION_COUNT, ALL_FAILED_AVG_LATENCY_SECONDS, CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT, dan TIMED_OUT_EXECUTION_COUNT tidak dilacak untuk DML yang dipartisi.

• Statistik untuk setiap pernyataan DML yang dipartisi yang dijalankan sebelumnya mungkin muncul dalam interval yang berbeda. SPANNER_SYS.QUERY_STATS_TOP_10MINUTE dan SPANNER_SYS.QUERY_STATS_TOP_HOUR memberikan tampilan gabungan untuk pernyataan DML berpartisi yang selesai dalam waktu 10 menit dan 1 jam. Untuk melihat statistik untuk pernyataan yang durasinya lebih dari 1 jam, lihat contoh kueri.

Skema tabel

EXECUTION_COUNT, AVG_LATENCY_SECONDS, dan LATENCY_DISTRIBUTION untuk kueri yang gagal mencakup kueri yang gagal karena sintaksis yang salah atau mengalami error sementara, tetapi berhasil saat dicoba lagi. Statistik ini tidak melacak pernyataan DML yang dipartisi yang gagal dan dibatalkan.

Statistik gabungan

Ada juga tabel yang melacak data gabungan untuk semua kueri yang statistiknya direkam oleh Spanner dalam jangka waktu tertentu:

• SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: Kueri selama interval 1 menit
• SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: Kueri selama interval 10 menit
• SPANNER_SYS.QUERY_STATS_TOTAL_HOUR: Kueri selama interval 1 jam

Tabel ini memiliki properti berikut:

• Setiap tabel berisi data untuk interval waktu yang tidak tumpang-tindih dengan panjang yang ditentukan oleh nama tabel.

• Interval didasarkan pada waktu jam. Interval 1 menit berakhir pada menit ke-1, interval 10 menit berakhir setiap 10 menit dimulai pada jam ke-1, dan interval 1 jam berakhir pada jam ke-1.

  Misalnya, pada pukul 11.59.30, interval terbaru yang tersedia untuk kueri SQL adalah:

  • 1 menit: 11.58.00–11.58.59 AM
  • 10 menit: 11.40.00–11.49.59 AM
  • 1 jam: 10.00.00–10.59.59

• Setiap baris berisi statistik untuk semua kueri yang dijalankan di database selama interval yang ditentukan, yang digabungkan. Hanya ada satu baris per interval waktu dan baris tersebut mencakup kueri yang selesai, kueri yang gagal, dan kueri yang dibatalkan oleh pengguna.

• Statistik yang diambil dalam tabel TOTAL mungkin mencakup kueri yang tidak diambil Spanner dalam tabel TOP.

• Beberapa kolom dalam tabel ini ditampilkan sebagai metrik di Cloud Monitoring. Metrik yang diekspos adalah:

  • Jumlah eksekusi kueri
  • Kegagalan kueri
  • Latensi kueri
  • Jumlah baris yang ditampilkan
  • Jumlah baris yang dipindai
  • Jumlah byte yang dikembalikan
  • Waktu CPU kueri

  Untuk mengetahui informasi selengkapnya, lihat Metrik Spanner.

Skema tabel

Retensi data

Setidaknya, Spanner menyimpan data untuk setiap tabel selama jangka waktu berikut:

• SPANNER_SYS.QUERY_STATS_TOP_MINUTE dan SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: Interval yang mencakup 6 jam sebelumnya.

• SPANNER_SYS.QUERY_STATS_TOP_10MINUTE dan SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: Interval yang mencakup 4 hari sebelumnya.

• SPANNER_SYS.QUERY_STATS_TOP_HOUR dan SPANNER_SYS.QUERY_STATS_TOTAL_HOUR: Interval yang mencakup 30 hari sebelumnya.

Contoh kueri

Bagian ini mencakup beberapa contoh pernyataan SQL yang mengambil statistik kueri. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, Google Cloud CLI, atau konsolGoogle Cloud .

Mencantumkan statistik dasar untuk setiap kueri dalam jangka waktu tertentu

Kueri berikut menampilkan data mentah untuk kueri teratas dalam satu menit sebelumnya:

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
ORDER BY interval_end DESC;

Mencantumkan statistik untuk pernyataan DML berpartisi yang berjalan lebih dari satu jam

Kueri berikut menampilkan jumlah eksekusi dan rata-rata baris yang ditulis oleh kueri DML yang dipartisi teratas dalam beberapa jam sebelumnya:

SELECT text,
       request_tag,
       interval_end,
       sum(execution_count) as execution_count
       sum(avg_rows_written*execution_count)/sum(execution_count) as avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE starts_with(text, "UPDATE") AND query_type = "PARTITIONED_QUERY"
group by text, request_tag, interval_end
ORDER BY interval_end DESC;

Mencantumkan kueri dengan penggunaan CPU tertinggi

Kueri berikut menampilkan kueri dengan penggunaan CPU tertinggi dalam satu jam sebelumnya:

SELECT text,
       request_tag,
       execution_count AS count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY total_cpu DESC;

Menemukan total jumlah eksekusi dalam jangka waktu tertentu

Kueri berikut menampilkan jumlah total kueri yang dieksekusi dalam interval 1 menit lengkap terbaru:

SELECT interval_end,
       execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_minute);

Menemukan latensi rata-rata untuk kueri

Kueri berikut menampilkan informasi latensi rata-rata untuk kueri tertentu:

SELECT avg_latency_seconds
FROM spanner_sys.query_stats_top_hour
WHERE text LIKE "SELECT x FROM table WHERE x=@foo;";

Menemukan latensi persentil ke-99 untuk kueri

Kueri berikut menampilkan persentil ke-99 waktu eksekusi di seluruh kueri yang dijalankan dalam 10 menit sebelumnya:

SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;

Membandingkan latensi Rata-rata dengan latensi persentil ke-99 membantu mengidentifikasi kemungkinan kueri pencilan dengan waktu eksekusi yang tinggi.

Menemukan kueri yang memindai data paling banyak

Anda dapat menggunakan jumlah baris yang dipindai oleh kueri sebagai ukuran jumlah data yang dipindai oleh kueri tersebut. Kueri berikut menampilkan jumlah baris yang dipindai oleh kueri yang dieksekusi pada jam sebelumnya:

SELECT text,
       execution_count,
       avg_rows_scanned
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_scanned DESC;

Menemukan pernyataan yang menulis data paling banyak

Anda dapat menggunakan jumlah baris yang ditulis (atau byte yang ditulis) oleh DML sebagai ukuran jumlah data yang diubah oleh kueri. Kueri berikut menampilkan jumlah baris yang ditulis oleh pernyataan DML yang dieksekusi pada jam sebelumnya:

SELECT text,
       execution_count,
       avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_written DESC;

Total penggunaan CPU di semua kueri

Kueri berikut menampilkan jumlah jam CPU yang digunakan pada jam sebelumnya:

SELECT (avg_cpu_seconds * execution_count / 60 / 60)
  AS total_cpu_hours
FROM spanner_sys.query_stats_total_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_hour);

Mencantumkan kueri yang gagal dalam jangka waktu tertentu

Kueri berikut menampilkan data mentah termasuk jumlah eksekusi dan latensi rata-rata kueri yang gagal untuk kueri teratas pada menit sebelumnya. Statistik ini tidak melacak pernyataan DML berpartisi yang gagal dan dibatalkan.

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       all_failed_execution_count,
       all_failed_avg_latency_seconds,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;

Menemukan total jumlah error dalam jangka waktu tertentu

Kueri berikut menampilkan jumlah total kueri yang gagal dieksekusi dalam interval 1 menit lengkap terbaru. Statistik ini tidak melacak pernyataan DML berpartisi yang gagal dan dibatalkan.

SELECT interval_end,
       all_failed_execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_minute)
ORDER BY interval_end;

Mencantumkan kueri yang paling sering mengalami waktu tunggu habis

Kueri berikut menampilkan kueri dengan jumlah waktu tunggu tertinggi dalam satu jam sebelumnya.

SELECT text,
       execution_count AS count,
       timed_out_execution_count AS timeout_count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY timed_out_execution_count DESC;

Menemukan latensi rata-rata eksekusi yang berhasil dan gagal untuk kueri

Kueri berikut menampilkan latensi rata-rata gabungan, latensi rata-rata untuk eksekusi yang berhasil, dan latensi rata-rata untuk eksekusi yang gagal untuk kueri tertentu. Statistik ini tidak melacak pernyataan DML yang dipartisi yang gagal dan dibatalkan.

SELECT avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text LIKE "select x from table where x=@foo;";

Memecahkan masalah penggunaan CPU yang tinggi atau peningkatan latensi kueri dengan statistik kueri

Statistik kueri berguna saat Anda perlu menyelidiki penggunaan CPU yang tinggi di database Spanner atau saat Anda hanya mencoba memahami bentuk kueri yang berat CPU di database Anda. Memeriksa kueri yang menggunakan sejumlah besar resource database memberi pengguna Spanner cara potensial untuk mengurangi biaya operasional dan mungkin meningkatkan latensi sistem umum.

Anda dapat menggunakan kode SQL atau dasbor Insight kueri untuk menyelidiki kueri bermasalah di database Anda. Topik berikut menunjukkan cara menyelidiki kueri tersebut menggunakan kode SQL.

Meskipun contoh berikut berfokus pada penggunaan CPU, langkah-langkah serupa dapat diikuti untuk memecahkan masalah latensi kueri yang tinggi dan menemukan kueri dengan latensi tertinggi. Cukup pilih interval waktu dan kueri menurut latensi, bukan penggunaan CPU.

Pilih jangka waktu yang akan diselidiki

Mulai penyelidikan Anda dengan mencari waktu saat aplikasi Anda mulai mengalami penggunaan CPU yang tinggi. Misalnya, jika masalah mulai terjadi sekitar 17.00 pada 24 Juli 2020 UTC.

Mengumpulkan statistik kueri untuk jangka waktu yang dipilih

Setelah memilih jangka waktu untuk memulai penyelidikan, kita akan melihat statistik yang dikumpulkan dalam tabel QUERY_STATS_TOTAL_10MINUTE pada waktu tersebut. Hasil kueri ini dapat menunjukkan bagaimana perubahan statistik CPU dan kueri lainnya selama jangka waktu tersebut.

Kueri berikut menampilkan statistik kueri gabungan dari 16.30 hingga 17.30 UTC inklusif. Kita menggunakan ROUND dalam kueri untuk membatasi jumlah tempat desimal untuk tujuan tampilan.

SELECT interval_end,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_rows,2) AS rows_returned,
       ROUND(avg_bytes,2) AS bytes,
       ROUND(avg_rows_scanned,2) AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS avg_cpu
FROM spanner_sys.query_stats_total_10minute
WHERE
  interval_end >= "2020-07-24T16:30:00Z"
  AND interval_end <= "2020-07-24T17:30:00Z"
ORDER BY interval_end;

Menjalankan kueri menghasilkan hasil berikut.

Dalam tabel sebelumnya, kita melihat bahwa waktu CPU rata-rata, kolom avg_cpu dalam tabel hasil, paling tinggi dalam interval yang ditandai yang berakhir pada pukul 17.00. Kita juga melihat jumlah baris yang dipindai jauh lebih tinggi secara rata-rata. Hal ini menunjukkan bahwa kueri yang lebih mahal dijalankan antara pukul 16.50 dan 17.00. Pilih interval tersebut untuk menyelidiki lebih lanjut di langkah berikutnya.

Menemukan kueri yang menyebabkan penggunaan CPU tinggi

Dengan interval waktu yang dipilih untuk diselidiki, kita sekarang membuat kueri tabel QUERY_STATS_TOP_10MINUTE. Hasil kueri ini dapat membantu menunjukkan kueri mana yang menyebabkan penggunaan CPU tinggi.

SELECT text_fingerprint AS fingerprint,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_cpu_seconds,3) AS cpu,
       ROUND(execution_count * avg_cpu_seconds,3) AS total_cpu
FROM spanner_sys.query_stats_top_10MINUTE
WHERE
  interval_end = "2020-07-24T17:00:00Z"
ORDER BY total_cpu DESC;

Menjalankan kueri ini akan menghasilkan hasil berikut.

2 kueri teratas, yang ditandai dalam tabel hasil, adalah pencilan dalam hal CPU dan latensi rata-rata, serta jumlah eksekusi dan total CPU. Selidiki kueri pertama yang tercantum dalam hasil ini.

Membandingkan operasi kueri dari waktu ke waktu

Setelah mempersempit penyelidikan, kita dapat mengalihkan perhatian ke tabel QUERY_STATS_TOP_MINUTE. Dengan membandingkan eksekusi dari waktu ke waktu untuk kueri tertentu, kita dapat mencari korelasi antara jumlah baris atau byte yang ditampilkan, atau jumlah baris yang dipindai dan CPU atau latensi yang tinggi. Penyimpangan dapat menunjukkan ketidakseragaman dalam data. Jumlah baris yang dipindai yang terus-menerus tinggi dapat menunjukkan kurangnya indeks yang sesuai atau pengurutan gabungan yang tidak optimal.

Selidiki kueri yang menunjukkan penggunaan CPU rata-rata tertinggi dan latensi tertinggi dengan menjalankan pernyataan berikut yang memfilter text_fingerprint kueri tersebut.

SELECT interval_end,
       ROUND(avg_latency_seconds,2) AS latency,
       avg_rows AS rows_returned,
       avg_bytes AS bytes_returned,
       avg_rows_scanned AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS cpu,
FROM spanner_sys.query_stats_top_minute
WHERE text_fingerprint = 5505124206529314852
ORDER BY interval_end DESC;

Menjalankan kueri ini akan menampilkan hasil berikut.

Dengan memeriksa hasil sebelumnya, kita dapat melihat bahwa jumlah baris yang dipindai, CPU yang digunakan, dan latensi semuanya berubah secara signifikan sekitar pukul 09.00. Untuk memahami mengapa angka-angka ini meningkat begitu drastis, kita akan memeriksa teks kueri dan melihat apakah ada perubahan dalam skema yang mungkin memengaruhi kueri.

Gunakan kueri berikut untuk mengambil teks kueri untuk kueri yang sedang kita selidiki.

SELECT text,
       text_truncated
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852
LIMIT 1;

Tindakan ini akan menampilkan hasil berikut.

Dengan memeriksa teks kueri yang ditampilkan, kita menyadari bahwa kueri tersebut memfilter kolom yang disebut o_custkey. Ini adalah kolom non-kunci di tabel orders. Ternyata, dulu ada indeks pada kolom tersebut yang dihapus sekitar pukul 09.00. Hal ini menjelaskan perubahan biaya untuk kueri ini. Kita dapat menambahkan indeks kembali atau, jika kueri jarang dijalankan, memutuskan untuk tidak memiliki indeks dan menerima biaya baca yang lebih tinggi.

Sejauh ini, penyelidikan kami berfokus pada kueri yang berhasil diselesaikan dan kami menemukan satu alasan mengapa database mengalami penurunan performa. Pada langkah berikutnya, kita akan berfokus pada kueri yang gagal atau dibatalkan dan menunjukkan cara memeriksa data tersebut untuk mendapatkan lebih banyak insight.

Menyelidiki kueri yang gagal

Kueri yang tidak berhasil diselesaikan tetap menggunakan resource sebelum waktunya habis, dibatalkan, atau gagal. Spanner melacak jumlah eksekusi dan resource yang digunakan oleh kueri yang gagal bersama dengan kueri yang berhasil. Statistik ini tidak melacak pernyataan DML yang dipartisi yang gagal dan dibatalkan.

Untuk memeriksa apakah kueri yang gagal merupakan kontributor signifikan terhadap pemanfaatan sistem, kita dapat memeriksa terlebih dahulu jumlah kueri yang gagal dalam interval waktu yang diinginkan.

SELECT interval_end,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS latency
FROM spanner_sys.query_stats_total_minute
WHERE
  interval_end >= "2020-07-24T16:50:00Z"
  AND interval_end <= "2020-07-24T17:00:00Z"
ORDER BY interval_end;

Untuk menyelidiki lebih lanjut, kita dapat mencari kueri yang kemungkinan besar akan gagal menggunakan kueri berikut.

SELECT interval_end,
       text_fingerprint,
       execution_count,
       avg_latency_seconds AS avg_latency,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS failed_latency,
       cancelled_or_disconnected_execution_count AS cancel_count,
       timed_out_execution_count AS to_count
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;

Seperti yang ditunjukkan tabel di atas, kueri dengan sidik jari 5505124206529314852 telah gagal beberapa kali selama interval waktu yang berbeda. Mengingat pola kegagalan seperti ini, akan menarik untuk membandingkan latensi operasi yang berhasil dan yang gagal.

SELECT interval_end,
       avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text_fingerprint = 5505124206529314852;

Menerapkan praktik terbaik

Setelah mengidentifikasi kueri kandidat untuk pengoptimalan, kita dapat melihat profil kueri dan mencoba mengoptimalkan menggunakan praktik terbaik SQL.

Langkah berikutnya

• Gunakan Kueri aktif terlama untuk menentukan kueri aktif yang berjalan paling lama.

• Pelajari lebih lanjut Menyelidiki penggunaan CPU yang tinggi.

• Pelajari alat Introspeksi lainnya.

• Pelajari informasi lain yang disimpan Spanner untuk setiap database di tabel skema informasi database.

• Pelajari lebih lanjut praktik terbaik SQL untuk Spanner.