Versi pengoptimal kueri Spanner

Halaman ini menjelaskan dan menyediakan histori berbagai versi pengoptimal kueri Spanner. Versi default saat ini adalah 6. Untuk mempelajari pengoptimal kueri lebih lanjut, lihat artikel Tentang pengoptimal kueri.

Spanner meluncurkan update pengoptimal kueri sebagai versi pengoptimal kueri baru. Secara default, setiap database mulai menggunakan versi terbaru pengoptimal setidaknya 30 hari setelah versi tersebut dirilis.

Jika menggunakan database dialek GoogleSQL, Anda dapat mengelola versi pengoptimal kueri yang digunakan kueri Anda. Sebelum menetapkan ke versi terbaru, Anda dapat membandingkan profil performa kueri antara versi lama dan versi terbaru. Untuk mempelajari lebih lanjut, lihat Mengelola pengoptimal kueri.

Histori versi pengoptimal kueri

Berikut adalah ringkasan pembaruan yang dilakukan pada pengoptimal kueri dalam setiap rilis.

Versi 6: 11 September 2023 (terbaru dan default)

  • Peningkatan batas pengiriman dan predikat yang mendorong melalui gabungan luar penuh.

  • Peningkatan estimasi kardinalitas dan model biaya.

  • Mengaktifkan pengoptimalan berbasis biaya untuk kueri DML.

Versi 5: 15 Juli 2022

  • Peningkatan model biaya untuk pemilihan indeks, pengelolaan distribusi, penempatan pengurutan, dan pemilihan GROUP BY.

  • Menambahkan dukungan untuk pemilihan algoritma join berbasis biaya yang memilih antara hash dan menerapkan join. Penggabungan penggabungan masih memerlukan penggunaan petunjuk kueri.

  • Menambahkan dukungan untuk komutatif gabungan berbasis biaya.

Versi 4: 1 Maret 2022

  • Peningkatan pada pemilihan indeks sekunder.

    • Meningkatkan penggunaan indeks sekunder pada gabungan antara tabel yang disisipkan.
    • Peningkatan cakupan penggunaan indeks sekunder.
    • Peningkatan pilihan indeks saat statistik pengoptimal sudah tidak berlaku.
    • Memilih indeks sekunder dengan predikat pada kolom terindeks terkemuka meskipun statistik pengoptimal tidak tersedia atau ukuran tabel dasar yang kecil.

  • Memperkenalkan gabungan hash single pass, yang diaktifkan oleh hash_join_execution petunjuk baru.

    Petunjuk Gabung:

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=hash_join, hash_join_execution=one_pass} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=hash_join, hash_join_execution=one_pass */ (...)

    Mode baru ini bermanfaat jika input sisi build dari penggabungan hash berukuran besar. Hash join one pass diharapkan akan memiliki performa yang lebih baik saat Anda mengamati hal-hal berikut di profil eksekusi kueri:

    • Jumlah eksekusi pada turunan kanan gabungan hash lebih besar daripada jumlah eksekusi pada operator hash join.
    • Latensi pada turunan kanan operator hash join juga tinggi.

    Secara default (hash_join_execution=multi_pass), jika input sisi build gabungan hash terlalu besar untuk dimuat dalam memori, sisi build akan dibagi menjadi beberapa batch dan kita mungkin memindai sisi pemeriksaan beberapa kali. Dengan mode baru (hash_join_execution=one_pass), gabungan hash akan mengalir ke disk jika input sisi build-nya tidak dapat dimuat dalam memori dan akan selalu memindai sisi probe sekali saja.

  • Peningkatan dalam pemilihan jumlah kunci yang digunakan untuk pencarian.

Versi 3: 1 Agustus 2021

  • Menambahkan algoritma join baru, merge join, diaktifkan menggunakan nilai petunjuk kueri JOIN METHOD baru.

    Petunjuk pernyataan:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

    /*@ join_method=merge_join */
SELECT ...

    Petunjuk bergabung:

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=merge_join} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=merge_join */ (...)

  • Menambahkan algoritma gabungan baru, mendorong gabungan hash siaran, diaktifkan menggunakan nilai petunjuk kueri JOIN METHOD baru.

    Petunjuk bergabung:

    GoogleSQL 

    SELECT ...
FROM (...)
JOIN@{join_method=push_broadcast_hash_join} (...)

    PostgreSQL 

    SELECT ...
FROM (...)
JOIN/*@ join_method=push_broadcast_hash_join} */ (...)

  • Memperkenalkan operator distributed merge union, yang diaktifkan secara default jika berlaku. Operasi ini meningkatkan performa kueri.

  • Peningkatan kecil pada performa pemindaian pada GROUP BY saat tidak ada agregat MAX atau MIN (atau HAVING MAX/MAX) dalam daftar SELECT. Sebelum perubahan ini, Spanner memuat kolom tambahan yang tidak dikelompokkan meskipun tidak diperlukan oleh kueri.

    Misalnya, perhatikan tabel berikut:

    GoogleSQL 

    CREATE TABLE myTable(
  a INT64,
  b INT64,
  c INT64,
  d INT64)
PRIMARY KEY (a, b, c);

    PostgreSQL 

    CREATE TABLE myTable(
  a bigint,
  b bigint,
  c bigint,
  d bigint,
  PRIMARY KEY(a, b, c)
);

    Sebelum perubahan ini, kueri berikut akan memuat kolom c meskipun tidak diperlukan oleh kueri.

    SELECT a, b
FROM myTable
GROUP BY a, b

  • Meningkatkan performa beberapa kueri dengan LIMIT saat ada operator penerapan silang yang diperkenalkan oleh gabungan dan kueri meminta hasil yang diurutkan dengan LIMIT. Setelah perubahan ini, pengoptimal menerapkan pengurutan dengan batas pada sisi input dari penerapan silang terlebih dahulu.

    Contoh:

    GoogleSQL 

    SELECT a2.*
FROM Albums@{FORCE_INDEX=_BASE_TABLE} a1
JOIN Albums@{FORCE_INDEX=_BASE_TABLE} a2 USING(SingerId)
ORDER BY a1.AlbumId
LIMIT 2;

    PostgreSQL 

    SELECT a2.*
FROM albums/*@ force_index=_base_table */ a1
JOIN albums/*@ force_index=_base_table */ a2 USING(singerid)
ORDER BY a1.albumid
LIMIT 2;

  • Meningkatkan performa kueri dengan mendorong lebih banyak komputasi melalui JOIN.

    Mendorong lebih banyak komputasi yang mungkin mencakup subkueri atau konstruksi struct melalui join. Tindakan tersebut akan meningkatkan performa kueri dengan beberapa cara seperti: Lebih banyak komputasi dapat dilakukan secara terdistribusi dan lebih banyak operasi yang bergantung pada komputasi yang didorong juga dapat didorong ke bawah. Misalnya, kueri memiliki batas dan tata urutan bergantung pada komputasi tersebut, batas juga dapat didorong melalui join.

    Contoh:

    SELECT
  t.ConcertDate,
  (
    SELECT COUNT(*) FROM UNNEST(t.TicketPrices) p WHERE p > 10
  ) AS expensive_tickets,
  u.VenueName
FROM Concerts t
JOIN Venues u ON t.VenueId = u.VenueId
ORDER BY expensive_tickets
LIMIT 2;

Versi 2: 1 Maret 2020

  • Menambahkan pengoptimalan dalam pemilihan indeks.
  • Meningkatkan performa predikat REGEXP_CONTAINS dan LIKE dalam keadaan tertentu.
  • Meningkatkan performa pemindaian pada GROUP BY dalam situasi tertentu.

Versi 1: 18 Juni 2019

  • Mencakup banyak pengoptimalan berbasis aturan seperti bentang bawah predikat, batas bentang bawah, penggabungan redundan, dan penghapusan ekspresi redundan, beberapa di antaranya.

  • Menggunakan statistik tentang data pengguna untuk memilih indeks yang akan digunakan untuk mengakses setiap tabel.

Langkah selanjutnya