Versiones del optimizador de consultas de Spanner

En esta página se describen las distintas versiones del optimizador de consultas de Spanner y se proporciona un historial de ellas. La versión predeterminada actual es la 7. Para obtener más información sobre el optimizador de consultas, consulta el artículo Acerca del optimizador de consultas.

Spanner lanza actualizaciones del optimizador de consultas como nuevas versiones del optimizador de consultas. De forma predeterminada, cada base de datos empieza a usar la versión más reciente del optimizador al menos 30 días después de que se haya lanzado esa versión.

Si usas una base de datos con dialecto de GoogleSQL, puedes gestionar la versión del optimizador de consultas que usan tus consultas. Antes de confirmar la última versión, puede comparar los perfiles de rendimiento de las consultas entre versiones anteriores y la más reciente. Para obtener más información, consulta Gestionar el optimizador de consultas.

Historial de versiones del optimizador de consultas

A continuación, se incluye un resumen de las actualizaciones realizadas en el optimizador de consultas en cada versión.

Versión 8: 28 de octubre del 2024 (la más reciente)

  • Las cláusulas WITH se tienen en cuenta a la hora de elegir planes basados en costes.

  • Se ha mejorado el rendimiento de las consultas de búsqueda indexada y de aplicación cruzada distribuida.

  • Se ha mejorado el JOIN reordenamiento.

  • Se ha mejorado el rendimiento de las consultas con cláusulas IN (...) grandes.

  • Se ha mejorado el rendimiento de GROUP BY en determinados casos.

  • Otras mejoras, como la gestión más eficiente de las consultas con LIMIT, claves externas y la selección de índices.

Versión 7: 22 de mayo del 2024 (predeterminada)

  • Se ha añadido compatibilidad con la selección de planes de unión de índices basada en costes.

  • Se ha añadido compatibilidad con la selección inteligente de planes de búsqueda frente a planes de análisis en función de las estadísticas de las consultas que no tienen predicados de búsqueda para todas las partes clave.

  • Se ha añadido compatibilidad con la selección de combinaciones hash basada en costes.

Versión 6: 11 de septiembre del 2023

  • Se han mejorado las inserciones de límites y predicados mediante combinaciones externas completas.

  • Se han mejorado la estimación de cardinalidad y el modelo de costes.

  • Se ha habilitado la optimización basada en costes para las consultas de DML.

Versión 5: 15 de julio del 2022

  • Modelo de costes mejorado para la selección de índices, la gestión de la distribución, la colocación de orden y la selección de GROUP BY.

  • Se ha añadido compatibilidad con la selección de algoritmos de unión basados en costes, que elige entre la unión de hash y la unión de aplicación. La combinación de fusión sigue requiriendo el uso de una sugerencia de consulta.

  • Se ha añadido compatibilidad con la conmutatividad de las uniones basada en costes.

Versión 4: 1 de marzo del 2022

  • Mejoras en la selección de índices secundarios.

    • Se ha mejorado el uso de índices secundarios en una unión entre tablas intercaladas.
    • Se ha mejorado el uso de índices secundarios de cobertura.
    • Se ha mejorado la selección de índices cuando las estadísticas del optimizador están obsoletas.
    • Prefiere los índices secundarios con predicados en las columnas indexadas principales, aunque las estadísticas del optimizador no estén disponibles o indiquen que la tabla base es pequeña.

  • Introduce la combinación de hash de una sola pasada, habilitada por la nueva sugerencia hash_join_execution.

    Pista para unirse:

    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 */ (...)

    El nuevo modo es útil cuando la entrada del lado de compilación de la combinación hash es grande. Se espera que la combinación hash de una pasada tenga un mejor rendimiento cuando observes lo siguiente en el perfil de ejecución de la consulta:

    • El número de ejecuciones en el elemento secundario de la derecha de la combinación hash es mayor que el número de ejecuciones en el operador de combinación hash.
    • La latencia del elemento secundario derecho del operador de combinación hash también es alta.

    De forma predeterminada (hash_join_execution=multi_pass), si la entrada del lado de compilación de la combinación 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 nuevo modo (hash_join_execution=one_pass), una combinación hash se volcará en el disco si la entrada del lado de compilación no cabe en la memoria y siempre analizará el lado de sondeo solo una vez.

  • Se ha mejorado la selección del número de teclas que se usan para buscar.

Versión 3: 1 de agosto del 2021

  • Añade un nuevo algoritmo de unión, la unión por combinación, que se habilita mediante un nuevo valor de sugerencia de consulta JOIN METHOD.

    Sugerencia de extracto:

    GoogleSQL 

    @{join_method=merge_join}
SELECT ...

    PostgreSQL 

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

    Sugerencia para unirse:

    GoogleSQL 

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

    PostgreSQL 

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

  • Añade un nuevo algoritmo de unión, la unión de hash de difusión push, que se habilita mediante un nuevo valor de sugerencia de consulta JOIN METHOD.

    Sugerencia para unirse:

    GoogleSQL 

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

    PostgreSQL 

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

  • Se introduce el operador unión de fusión distribuida, que está habilitado de forma predeterminada cuando procede. Esta operación mejora el rendimiento de las consultas.

  • Una pequeña mejora en el rendimiento de un análisis en GROUP BY cuando no hay ningún agregado MAX o MIN (o HAVING MAX/MIN) en la lista SELECT. Antes de este cambio, Spanner cargaba la columna adicional no agrupada aunque la consulta no la necesitara.

    Por ejemplo, consulta la siguiente tabla:

    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)
);

    Antes de este cambio, la siguiente consulta habría cargado la columna c aunque no fuera necesaria para la consulta.

    SELECT a, b
FROM myTable
GROUP BY a, b

  • Mejora el rendimiento de algunas consultas con LIMIT cuando hay un operador de aplicación cruzada introducido por las combinaciones y la consulta pide resultados ordenados con LIMIT. Después de este cambio, el optimizador aplica la ordenación con el límite en el lado de entrada de la aplicación cruzada primero.

    Ejemplo:

    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;

  • Mejora el rendimiento de las consultas al enviar más cálculos a través de JOIN.

    Transfiere más cálculos, que pueden incluir una subconsulta o una construcción struct, a través de la unión. De esta forma, se mejora el rendimiento de las consultas de varias formas: se pueden realizar más cálculos de forma distribuida y también se pueden enviar más operaciones que dependan de los cálculos enviados. Por ejemplo, si la consulta tiene un límite y el orden de clasificación depende de esos cálculos, el límite también se puede aplicar a través de la combinación.

    Ejemplo:

    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ón 2: 1 de marzo del 2020

  • Añade optimizaciones en la selección de índices.
  • Mejora el rendimiento de los predicados REGEXP_CONTAINS y LIKE en determinadas circunstancias.
  • Mejora el rendimiento de un análisis en GROUP BY en determinadas situaciones.

Versión 1: 18 de junio del 2019

  • Incluye muchas optimizaciones basadas en reglas, como la inserción de predicados, la inserción de límites, la eliminación de uniones y expresiones redundantes, entre otras.

  • Usa estadísticas sobre los datos de usuario para seleccionar el índice que se va a usar para acceder a cada tabla.

Siguientes pasos