Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describe y proporciona un historial de las distintas versiones del optimizador de consultas de Spanner. La versión predeterminada actual es la 7.
Para obtener más información sobre el optimizador de consultas, consulta Acerca del optimizador de consultas.
Spanner lanza actualizaciones del optimizador de consultas como nuevas versiones del optimizador. De forma predeterminada, cada base de datos comienza a usar la versión más reciente del optimizador, al menos, 30 días después de que se publica.
Si usas una base de datos de dialecto de GoogleSQL, puedes administrar la versión del optimizador de consultas que usan tus consultas. Antes de confirmar la versión más reciente, puedes comparar
los perfiles de rendimiento de las consultas entre las versiones anteriores y la más reciente. Para obtener más información, consulta Administra el optimizador de consultas.
Historial de versiones del optimizador de consultas
A continuación, se muestra un resumen de las actualizaciones realizadas en el optimizador de consultas en cada versión.
Versión 8: 28 de octubre de 2024 (la más reciente)
Las cláusulas WITH se tienen en cuenta cuando se eligen planes basados en el costo.
Se mejoró el rendimiento de las consultas de búsqueda indexada y de aplicación cruzada distribuidas.
Se mejoró el reordenamiento de JOIN.
Se mejoró el rendimiento de las consultas con cláusulas IN (...) grandes.
Se mejoró el rendimiento de GROUP BY en ciertos casos.
Otras mejoras, como el manejo más eficiente de las consultas con LIMIT, las claves foráneas y la selección de índices
Versión 7: 22 de mayo de 2024 (predeterminada)
Se agregó compatibilidad para la selección basada en el costo de los planes de unión de índices.
Se agregó compatibilidad con la selección inteligente de planes de búsqueda en comparación con los de escaneo según las estadísticas de las consultas que no tienen predicados que se pueden buscar para todas las partes clave.
Se agregó compatibilidad con la selección basada en el costo de las uniones de hash.
Versión 6: 11 de septiembre de 2023
Se mejoraron el envío de límites y el envío de predicados a través de combinaciones externas completas.
Se mejoró la estimación de cardinalidad y el modelo de costos.
Se habilitó la optimización basada en el costo para las consultas de DML.
Versión 5: 15 de julio de 2022
Se mejoró el modelo de costos para la selección de índices, la administración de distribución, la ubicación de ordenamiento y la selección de GROUP BY.
Se agregó compatibilidad con la selección de algoritmo de unión basada en el costo que elige entre la unión de hash y la unión de aplicación. La combinación de uniones aún requiere el uso de una sugerencia de consulta.
Se agregó compatibilidad con la conmutatividad de la unión basada en el costo.
Versión 4: 1 de marzo de 2022
Se realizaron mejoras en la selección de índices secundarios.
Se mejoró el uso del índice secundario en una unión entre tablas intercaladas.
Se mejoró el uso del índice secundario de cobertura.
Se mejoró la selección de índices cuando las estadísticas del optimizador están desactualizadas.
Prefiere los índices secundarios con predicados en las columnas indexadas principales, incluso si las estadísticas del optimizador no están disponibles o si se informa que la tabla base es pequeña.
Se introduce la unión de hash de un solo paso, habilitada por la nueva sugerencia hash_join_execution.
La cantidad de ejecuciones en el subnivel derecho de la unión hash es mayor que la cantidad de ejecuciones en el operador de unión hash.
La latencia en el elemento secundario derecho del operador de unión hash también es alta.
De forma predeterminada (hash_join_execution=multi_pass), si la entrada del lado de compilación de la unión de hash es demasiado grande para caber en la memoria, el lado de compilación se divide en varios lotes y es posible que analicemos el lado de sondeo varias veces. Con el modo nuevo (hash_join_execution=one_pass), una unión hash se volcará en el disco si su entrada del lado de compilación no puede caber en la memoria y siempre analizará el lado de sondeo solo una vez.
Se mejoró la selección de la cantidad de teclas que se usan para el salto.
Versión 3: 1 de agosto de 2021
Agrega un nuevo algoritmo de combinación, la combinación de unión, que se habilita con un nuevo valor de sugerencia de consulta JOIN METHOD.
Agrega un nuevo algoritmo de combinación, la combinación hash de transmisión push, habilitada con un nuevo valor de sugerencia de consulta JOIN METHOD.
Se presenta el operador de unión de combinación distribuida, que se habilita de forma predeterminada cuando corresponde. Esta operación mejora el rendimiento de las consultas.
Una pequeña mejora en el rendimiento de un análisis en un GROUP BY cuando no hay una agregación MAX o MIN (o HAVING MAX/MAX) en la lista SELECT.
Antes de este cambio, Spanner cargaba la columna adicional no agrupada incluso si la consulta no la necesitaba.
Antes de este cambio, la siguiente consulta habría cargado la columna c, aunque esta no sea obligatoria.
SELECTa,bFROMmyTableGROUPBYa,b
Mejora el rendimiento de algunas consultas con LIMIT cuando hay un operador de aplicación cruzada que introducen las uniones y la consulta solicita resultados ordenados con LIMIT. Después de este cambio, el optimizador aplica primero la ordenación con el límite en el lado de entrada de la aplicación cruzada.
Mejora el rendimiento de las consultas, ya que envía más cálculos a través de JOIN.
Envía más cálculos que pueden incluir una subconsulta o una construcción de struct a través de la unión. Esto mejora el rendimiento de las consultas de varias maneras, por ejemplo:
Se pueden realizar más cálculos de forma distribuida y también se pueden enviar más operaciones
que dependen de los cálculos enviados. Por ejemplo, si la consulta tiene un límite y el orden de clasificación depende de esas operaciones, el límite también se puede pasar a través de la unión.
Mejora el rendimiento de los predicados REGEXP_CONTAINS y LIKE en ciertas circunstancias.
Mejora el rendimiento de un análisis en un GROUP BY en ciertas situaciones.
Versión 1: 18 de junio de 2019
Incluye muchas optimizaciones basadas en reglas, como el pushdown del predicado, el límite de pushdown, la unión redundante y la eliminación de expresiones redundantes, por nombrar algunas.
Usa las estadísticas de los datos del usuario para seleccionar el índice que se usará para acceder a cada tabla.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-05 (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)."]]