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 6. 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 una consulta nueva del optimizador. De forma predeterminada, cada base de datos comienza a usar la última versión de el optimizador no antes de los 30 días posteriores al lanzamiento de esa versión.
Si usas una base de datos de dialectos de GoogleSQL, puedes administrar la versión del optimizador de consultas. que usan tus consultas. Antes de comprometerte con la versión más reciente, puedes comparar para consultar perfiles de rendimiento entre versiones anteriores y la más reciente. Para Para obtener más información, consulta Administra el optimizador de consultas.
Historial de versiones del optimizador de consultas
A continuación, se presenta un resumen de las actualizaciones realizadas en el optimizador de consultas en cada lanzamiento.
Versión 7: 22 de mayo de 2024 (más reciente)
Se agregó compatibilidad para la selección basada en costos de planes de unión de índices.
Se agregó compatibilidad con la selección inteligente de planes de búsqueda y análisis basados en estadísticas de las consultas que no tienen predicados que se pueden buscar para todas las partes clave.
Se agregó compatibilidad para la selección basada en costos de uniones hash.
Versión 6: 11 de septiembre de 2023 (predeterminada)
Mejoras en el envío de límites y el envío de predicados a través de uniones externas completas.
Estimación de cardinalidad y modelo de costos mejorados
Se habilitó la optimización basada en costos para consultas DML.
Versión 5: 15 de julio de 2022
Modelo de costos mejorado para la selección de índices, la administración de la distribución y la ordenación posición y la selección de
GROUP BY
.Se agregó compatibilidad con la selección del algoritmo de unión basada en el costo que elige entre generar un hash y aplicar unión. La combinación de combinación aún requiere el uso de una sugerencia de consulta.
Se agregó compatibilidad con la conmutatividad de uniones basadas en costos.
Versión 4: 1 de marzo de 2022
Mejoras en la selección de índices secundarios
- Se mejoró el uso de índices secundarios en una unión entre tablas intercaladas.
- Se mejoró la cobertura del uso de índices secundarios.
- Se mejora la selección de índices cuando las estadísticas del optimizador están desactualizadas.
- Opta por índices secundarios con predicados en las principales columnas indexadas incluso Si las estadísticas del optimizador no están disponibles o informa la tabla base es pequeño.
Presenta la unión hash de un solo pase, habilitada por la nueva sugerencia
hash_join_execution
Sugerencia de unión:
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 modo nuevo es beneficioso cuando la entrada complementaria de compilación de la unión hash. es grande. Se espera que la unión hash de un solo pase tenga un mejor rendimiento cuando observes lo siguiente en el perfil de ejecución de consultas:
- La cantidad de ejecuciones en el elemento secundario derecho de la unión hash es mayor que la cantidad de ejecuciones del 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 complementaria de compilación de la unión hash es demasiado grande para caber en la memoria, el lado de la compilación se divide en en varios lotes y es posible que analicemos el lado del sondeo varias veces. Con la modo nuevo (hash_join_execution=one_pass
), una unión hash se derramará al disco si su entrada complementaria de compilación no cabe en la memoria y siempre analizará el sondeo una sola vez.Una mejora en la selección de cuántas teclas se usan para buscar.
Versión 3: 1 de agosto de 2021
Agrega un nuevo algoritmo de unión, unión de combinación, habilitado con un nuevo MÉTODO DE UNIÓN el valor de la sugerencia de la consulta.
Sugerencia de sentencia:
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 */ (...)
Agrega un nuevo algoritmo de unión, unión hash de transmisión push, habilitada con un nuevo Valor de sugerencia de consulta de 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} */ (...)
Presenta la 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 por debajo de un
GROUP BY
cuando no hay un agregado 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.Por ejemplo, considera 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 había cargado la columna
c
incluso aunque no es necesaria para la consulta.SELECT a, b FROM myTable GROUP BY a, b
Mejora el rendimiento de algunas consultas con
LIMIT
cuando hay una el operador de aplicación cruzada ingresado por las uniones y la consulta solicita ordenar resultados con LIMIT. Después de este cambio, el optimizador aplica el orden con el límite del 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 mediante el envío de más procesamientos 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. Eso mejora el rendimiento de las consultas de las siguientes maneras: Se pueden realizar más cálculos de forma distribuida y se pueden realizar más operaciones que dependen de los cálculos enviados también se pueden impulsar. Para ejemplo, la consulta tiene un límite y el orden de clasificación depende de esos de procesamiento, el límite también se puede enviar a través de la unió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 de 2020
- Agrega optimizaciones en la selección de índices.
- Mejora el rendimiento de los predicados
REGEXP_CONTAINS
yLIKE
en determinadas 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 estadísticas sobre los datos del usuario a fin de seleccionar qué índice usar para acceder a cada uno desde una tabla de particiones.
¿Qué sigue?
- Para obtener más información sobre el optimizador de consultas, consulta Acerca del optimizador de consultas.
- Para administrar la versión del optimizador y el paquete de estadísticas de tu situación, consulta Administra el optimizador de consultas.