Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini menjelaskan dan memberikan histori berbagai versi pengoptimal kueri
Spanner. Versi default saat ini adalah 7.
Untuk mempelajari pengoptimal kueri lebih lanjut, lihat Tentang pengoptimal kueri.
Spanner meluncurkan update pengoptimal kueri sebagai versi pengoptimal kueri
baru. Secara default, setiap database mulai menggunakan pengoptimal versi terbaru paling lambat 30 hari setelah versi tersebut dirilis.
Jika menggunakan database dialek GoogleSQL, Anda dapat mengelola versi pengoptimal kueri
yang digunakan kueri Anda. Sebelum berkomitmen ke versi terbaru, Anda dapat membandingkan
profil performa kueri antara versi sebelumnya dan versi terbaru. Untuk
mempelajari lebih lanjut, lihat Mengelola pengoptimal kueri.
Histori versi pengoptimal kueri
Berikut adalah ringkasan update yang dilakukan pada pengoptimal kueri di setiap
rilis.
Versi 8: 28 Oktober 2024 (terbaru)
Klausul WITH dipertimbangkan saat membuat pilihan paket berbasis biaya.
Meningkatkan performa kueri penelusuran terdistribusi dan kueri penelusuran yang diindeks.
Peningkatan pengurutan ulang JOIN.
Meningkatkan performa kueri dengan klausa IN (...) yang besar.
Meningkatkan performa GROUP BY dalam kasus tertentu.
Peningkatan lainnya termasuk penanganan kueri yang lebih efisien dengan LIMIT,
kunci asing, dan pemilihan indeks.
Versi 7: 22 Mei 2024 (default)
Menambahkan dukungan untuk pemilihan paket gabungan indeks berdasarkan biaya.
Menambahkan dukungan untuk pemilihan cerdas rencana penelusuran versus pemindaian berdasarkan
statistik untuk kueri yang tidak memiliki predikat yang dapat ditelusuri untuk semua bagian kunci.
Menambahkan dukungan untuk pemilihan join hash berbasis biaya.
Versi 6: 11 September 2023
Meningkatkan pendorongan batas dan pendorongan predikat melalui join luar penuh.
Estimasi kardinalitas dan model biaya yang ditingkatkan.
Mengaktifkan pengoptimalan berbasis biaya untuk kueri DML.
Versi 5: 15 Juli 2022
Meningkatkan model biaya untuk pemilihan indeks, pengelolaan distribusi, penempatan
urutan, dan pemilihan GROUP BY.
Menambahkan dukungan untuk pemilihan algoritma join berbasis biaya yang memilih antara
hash dan menerapkan join. Join penggabungan masih memerlukan penggunaan petunjuk kueri.
Menambahkan dukungan untuk komutabilitas join berbasis biaya.
Versi 4: 1 Maret 2022
Peningkatan pada pemilihan indeks sekunder.
Meningkatkan penggunaan indeks sekunder dalam penggabungan antara tabel yang diselingi.
Meningkatkan penggunaan indeks sekunder yang mencakup.
Peningkatan pemilihan indeks saat statistik pengoptimal sudah tidak berlaku.
Pilih indeks sekunder dengan predikat pada kolom utama yang diindeks meskipun
statistik pengoptimal tidak tersedia atau melaporkan bahwa tabel dasar
kecil.
Memperkenalkan join hash satu jalur, yang diaktifkan oleh petunjuk
hash_join_execution baru.
Jumlah eksekusi pada turunan kanan hash join 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
join hash terlalu besar untuk muat dalam memori, sisi build akan dibagi menjadi
beberapa batch dan kita dapat memindai sisi probe beberapa kali. Dengan
mode baru (hash_join_execution=one_pass), join hash akan dialihkan ke disk jika
input sisi build-nya tidak dapat muat dalam memori dan akan selalu memindai sisi
probe hanya sekali.
Peningkatan dalam memilih jumlah kunci yang digunakan untuk pencarian.
Versi 3: 1 Agustus 2021
Menambahkan algoritma join baru, join penggabungan, yang diaktifkan menggunakan nilai petunjuk kueri JOIN METHOD baru.
Memperkenalkan operator gabungan penggabungan terdistribusi, yang diaktifkan secara default jika berlaku. Operasi ini
meningkatkan performa kueri.
Peningkatan kecil pada performa pemindaian dalam 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.
Sebelum perubahan ini, kueri berikut akan memuat kolom c meskipun
tidak diperlukan oleh kueri.
SELECTa,bFROMmyTableGROUPBYa,b
Meningkatkan performa beberapa kueri dengan LIMIT jika ada
operator cross apply yang diperkenalkan oleh join dan kueri meminta hasil
yang diurutkan dengan LIMIT. Setelah perubahan ini, pengoptimal akan menerapkan pengurutan
dengan batas di sisi input penerapan silang terlebih dahulu.
Meningkatkan performa kueri dengan mendorong lebih banyak komputasi melalui JOIN.
Mendorong lebih banyak komputasi yang dapat mencakup subkueri atau konstruksi struct
melalui join. Hal ini 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 urutan pengurutan bergantung pada komputasi
tersebut, maka batas juga dapat didorong melalui join.
Meningkatkan performa predikat REGEXP_CONTAINS dan LIKE dalam
keadaan tertentu.
Meningkatkan performa pemindaian dalam GROUP BY dalam situasi tertentu.
Versi 1: 18 Juni 2019
Mencakup banyak pengoptimalan berbasis aturan seperti pushdown predikat, pushdown batas, join redundan, dan penghapusan ekspresi redundan, untuk beberapa nama.
Menggunakan statistik pada data pengguna untuk memilih indeks yang akan digunakan untuk mengakses setiap
tabel.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-11 UTC."],[],[],null,["# Spanner query optimizer versions\n\nThis page describes and provides a history of the various Spanner query\noptimizer versions. The current default version is 7.\nTo learn more about the query optimizer, see [About query optimizer](/spanner/docs/query-optimizer/overview).\n\nSpanner rolls out query optimizer updates as new query\noptimizer versions. By default, each database starts using the latest version of\nthe optimizer no sooner than 30 days after that version has been released.\n\nIf you're using a GoogleSQL-dialect database, you can manage the query optimizer version\nthat your queries use. Before committing to the latest version, you can compare\nquery performance profiles between earlier versions and the latest version. To\nlearn more, see [Manage the query optimizer](/spanner/docs/query-optimizer/manage-query-optimizer).\n\nQuery optimizer version history\n-------------------------------\n\nThe following is a summary of the updates made to the query optimizer in each\nrelease.\n\n\u003cbr /\u003e\n\n### Version 8: October 28th, 2024 (latest)\n\n- `WITH` clauses are considered when making cost-based plan choices.\n\n- Improved performance of distributed cross apply and indexed lookup queries.\n\n- Improved `JOIN` reordering.\n\n- Improved performance of queries with large `IN (...)` clauses.\n\n- Improved `GROUP BY` performance in certain cases.\n\n- Other improvements including more efficient handling of queries with `LIMIT`,\n foreign keys, and index selection.\n\n### Version 7: May 22nd, 2024 (default)\n\n- Added support for cost-based selection of index union plans.\n\n- Added support for the smart selection of seek versus scan plans based on\n statistics for queries that don't have seekable predicates for all key parts.\n\n- Added support for cost-based selection of hash joins.\n\n### Version 6: September 11th, 2023\n\n- Improved limit pushing and predicate pushing through full outer joins.\n\n- Improved cardinality estimation and cost model.\n\n- Enabled cost-based optimization for DML queries.\n\n### Version 5: July 15th, 2022\n\n- Improved cost model for index selection, distribution management, sort\n placement and `GROUP BY` selection.\n\n- Added support for cost-based join algorithm selection that chooses between\n hash and apply join. Merge join still requires using a query hint.\n\n- Added support for cost-based join commutativity.\n\n### Version 4: March 1st, 2022\n\n- Improvements to secondary index selection.\n\n - Improved secondary index usage under a join between interleaved tables.\n - Improved covering secondary index usage.\n - Improved index selection when optimizer statistics are outdated.\n - Prefer secondary indexes with predicates on leading indexed columns even if the optimizer statistics are not available or report the base table is small.\n- Introduces single pass hash join, enabled by the new hint\n `hash_join_execution`.\n\n Join Hint: \n\n ### GoogleSQL\n\n SELECT ...\n FROM (...)\n JOIN@{join_method=hash_join, hash_join_execution=one_pass} (...)\n\n ### PostgreSQL\n\n SELECT ...\n FROM (...)\n JOIN/*@ join_method=hash_join, hash_join_execution=one_pass */ (...)\n\n The new mode is beneficial when the [build side input of the hash join](/spanner/docs/query-execution-operators#hash-join)\n is large. One pass hash join is expected to have better performance when you\n observe the following in the [query execution profile](/spanner/docs/tune-query-with-visualizer):\n - The number of executions on the right child of the hash join is larger than the number of executions on the hash join operator.\n - The latency on the right child of the hash join operator is also high.\n\n By default (`hash_join_execution=multi_pass`), if the build side input of\n the hash join is too large to fit in memory, the build side is split into\n multiple batches and we might scan the probe side multiple times. With the\n new mode (`hash_join_execution=one_pass`), a hash join will spill to disk if\n its build side input cannot fit in memory and will always scan the probe\n side only once.\n- An improvement in selecting how many keys are used for seeking.\n\n### Version 3: August 1st, 2021\n\n- Adds a new join algorithm, merge join, enabled using a new [JOIN METHOD](/spanner/docs/reference/standard-sql/query-syntax#join-methods)\n query hint value.\n\n Statement hint: \n\n ### GoogleSQL\n\n @{join_method=merge_join}\n SELECT ...\n\n ### PostgreSQL\n\n /*@ join_method=merge_join */\n SELECT ...\n\n Join hint: \n\n ### GoogleSQL\n\n SELECT ...\n FROM (...)\n JOIN@{join_method=merge_join} (...)\n\n ### PostgreSQL\n\n SELECT ...\n FROM (...)\n JOIN/*@ join_method=merge_join */ (...)\n\n- Adds a new join algorithm, push broadcast hash join, enabled using a new\n [JOIN METHOD](/spanner/docs/reference/standard-sql/query-syntax#join-methods) query hint value.\n\n Join hint: \n\n ### GoogleSQL\n\n SELECT ...\n FROM (...)\n JOIN@{join_method=push_broadcast_hash_join} (...)\n\n ### PostgreSQL\n\n SELECT ...\n FROM (...)\n JOIN/*@ join_method=push_broadcast_hash_join} */ (...)\n\n- Introduces the [distributed merge union](/spanner/docs/query-execution-operators#distributed-merge-union)\n operator, which is enabled by default when applicable. This operation\n improves the performance of queries.\n\n- A small improvement to the performance of a scan under a `GROUP BY` when\n there is no MAX or MIN aggregate (or HAVING MAX/MAX) in the SELECT list.\n Prior to this change, Spanner loaded the extra non-grouped\n column even if it was not required by the query.\n\n For example, consider the following table: \n\n ### GoogleSQL\n\n CREATE TABLE myTable(\n a INT64,\n b INT64,\n c INT64,\n d INT64)\n PRIMARY KEY (a, b, c);\n\n ### PostgreSQL\n\n CREATE TABLE myTable(\n a bigint,\n b bigint,\n c bigint,\n d bigint,\n PRIMARY KEY(a, b, c)\n );\n\n Prior to this change, the following query would have loaded column `c` even\n though it is not required by the query. \n\n SELECT a, b\n FROM myTable\n GROUP BY a, b\n\n- Improves the performance of some queries with `LIMIT` when there is a\n cross apply operator introduced by joins and the query asks for sorted\n results with LIMIT. After this change, the optimizer applies the sorting\n with the limit on the input side of cross apply first.\n\n Example: \n\n ### GoogleSQL\n\n SELECT a2.*\n FROM Albums@{FORCE_INDEX=_BASE_TABLE} a1\n JOIN Albums@{FORCE_INDEX=_BASE_TABLE} a2 USING(SingerId)\n ORDER BY a1.AlbumId\n LIMIT 2;\n\n ### PostgreSQL\n\n SELECT a2.*\n FROM albums/*@ force_index=_base_table */ a1\n JOIN albums/*@ force_index=_base_table */ a2 USING(singerid)\n ORDER BY a1.albumid\n LIMIT 2;\n\n- Improves query performance by pushing more computations through `JOIN`.\n\n Pushes more computations which may include a subquery or struct construction\n through join. That improves the query performance in a few ways such as:\n More computations can be done in a distributed fashion and more operations\n that depend on the pushed computations can be pushed down as well. For\n example, the query has a limit and the sort order depends on those\n computations, then the limit can be pushed through join as well.\n\n Example: \n\n SELECT\n t.ConcertDate,\n (\n SELECT COUNT(*) FROM UNNEST(t.TicketPrices) p WHERE p \u003e 10\n ) AS expensive_tickets,\n u.VenueName\n FROM Concerts t\n JOIN Venues u ON t.VenueId = u.VenueId\n ORDER BY expensive_tickets\n LIMIT 2;\n\n\u003cbr /\u003e\n\n### Version 2: March 1st, 2020\n\n- Adds optimizations in index selection.\n- Improves the performance of `REGEXP_CONTAINS` and `LIKE` predicates under certain circumstances.\n- Improves the performance of a scan under a `GROUP BY` in certain situations.\n\n\u003cbr /\u003e\n\n### Version 1: June 18th, 2019\n\n- Includes many rule based optimizations such as predicate pushdown, limit\n pushdown, redundant join and redundant expression removal, to name a few.\n\n- Uses statistics on user data to select which index to use to access each\n table.\n\nWhat's next\n-----------\n\n- To learn more about the query optimizer, see [About query optimizer](/spanner/docs/query-optimizer/overview).\n- To manage both the optimizer version and statistics package for your scenario, see [Manage the query optimizer](/spanner/docs/query-optimizer/manage-query-optimizer)."]]